looking for suitable 74HC... device(s) for a given truth table

[ilmenator]

Hi all,

I'm struggling with implementing the following truth table in hardware; any hints on what (combination of) 74HC... devices could do the trick are greatly appreciated. Here is the problem:

[table]

[tr][td]  Input1  [/td][td]  Input2  [/td][td]  Input3  [/td][td]  Input4  [/td][td]  Output1  [/td][td]  Output2  [/td][/tr]

[tr][td]

0

[/td][td]

0

[/td][td]

0

[/td][td]

x

[/td][td]

0

[/td][td]

1

[/td][/tr]

[tr][td]

0

[/td][td]

0

[/td][td]

1

[/td][td]

x

[/td][td]

1

[/td][td]

1

[/td][/tr]

[tr][td]

0

[/td][td]

1

[/td][td]

x

[/td][td]

0

[/td][td]

0

[/td][td]

1

[/td][/tr]

[tr][td]

0

[/td][td]

1

[/td][td]

x

[/td][td]

1

[/td][td]

1

[/td][td]

1

[/td][/tr]

[tr][td]

1

[/td][td]

0

[/td][td]

0

[/td][td]

x

[/td][td]

1

[/td][td]

0

[/td][/tr]

[tr][td]

1

[/td][td]

0

[/td][td]

1

[/td][td]

x

[/td][td]

1

[/td][td]

1

[/td][/tr]

[tr][td]

1

[/td][td]

1

[/td][td]

x

[/td][td]

0

[/td][td]

1

[/td][td]

0

[/td][/tr]

[tr][td]

1

[/td][td]

1

[/td][td]

x

[/td][td]

1

[/td][td]

1

[/td][td]

1

[/td][/tr]

[/table]

I have looked at 74HC151 and HC153, but they only do part of what I need - and then it becomes rather complex... Also, some methodological hints on how to tackle such problems in general would be helpful  ???

Thanks, ilmenator

[TK.]

Manual Optimisation: http://de.wikipedia.org/wiki/Karnaugh-Veitch-Diagramm

Experts would quickly write the terms in Verilog or VHDL, and push the "synthesis" button ;)

Best Regards, Thorsten.

[Wilba]

If it isn't a time-critical application (i.e. you don't mind a few microseconds of latency, inputs don't change very quickly), you could use one of the cheap, 8-pin burn-once PICs like a PIC12C508A to simulate an arrangement of AND, OR, XOR gates. I mean, if the inputs are just switch pushes and not some kind of serial communication, this would work fine. (You may prefer a PIC with the ability to reprogram it, in which case the common PIC16F84 would be ideal.)

[TK.]

If equipment doesn't matter, you could use a PLA (e.g. years ago I used GALs for such purposes)

Or if size/PCB area doesn't matter: just use a memory, e.g. an EPROM with parallel interface, and program the complete logic table into it.

Best Regards, Thorsten.

[ilmenator]

Thanks for these great comments - the Wikipedia link was extremely helpful!

Now, what I did come up with is two circuits that synthesize my output signals, see what I attached. The question now is, whether I am better off doing this in discrete logic, in a small PIC or in EEPROM memory, as Thorsten's last suggestion was. I may explain a little more:

I've been fiddling around with an idea for more than two years now. It is about a memory extension of my beloved Wavestation synthesizer. So, the PIC-based device should emulate bot a PCM card (this way, all the additional wave forms - key word 'synth & Time Slice'  ;D - could be easily accessed) and a RAM card.

My main problem was until now the large memory I would need to store the PCM waveforms and the sound patch data - I tried interfacing a CF card to the PIC last summer but for some reasons beyond my understanding that did not work out. As I read between the lines that TK is working on MIDIbox SD, I guess this is nothing I should worry about any more, so I concentrate on the core part of my device. The main "problem" is that both the PIC and the Wavestation will have to access the address and data buses at some given time without influencing each other. I know about techniques to separate the buses using 74HCT245 and FST3245, now I am working on the \CE, \WE and \OE signals. The problem statement above is for the \CE line, the attached pictures (hopefully) make it more clear.

As I am talking about bus accesses, this is probably a bit time critical - at least probably more than Wilba's suggestion would permit. Also, I expect at least a bit of interest in this device (e.g. the Synth & Time Slice PCM cardset goes for ridiculous prices on ebay), so it should be DIY friendly - whatever I can do using the MBHP burner would be fine.

Best regards, ilmenator

[TK.]

Great idea! :)

Do you know the maximum bus frequency? I fear, that a PIC cannot handle it...

It sounds like a typical FPGA project. There are cheap evaluation boards available with huge external SRAMs. You could also interface a CF or SD card in addition + the original PCM card (mostly there are hundreds of IOs), but it would require some HDL skills. However, maybe an ideal project to get into this topic :)

Best Regards, Thorsten.

[ilmenator]

Well,

in my design the PIC is only used to control the device and to manage the user interface. I have an MBHP based prototype up and running that can read the content of a Wavestation RAM/ROM card into a bankstick and write this back to the WS RAM card. It also displays the card name on the LCD.

In the attached PDF you can see the basic structure of the next generation device (PCM section not shown - only contains the sound patch data section). K2 connects to the MBHP core module J15, K3 connects to the Wavestation card slot. K1 is the receptor for Wavestation cards (don't be fooled by the SUB-D37 name tag).

IC6 is a 32kx8 SRAM memory, that's exactly the size of a Wavestation RAM/ROM card. The user can select between "Card" access and "SRAM" access - so, the Wavestation either sees the Card or the SRAM. It is extremely important to me that the WS does not see any difference between my device and an ordinary RAM card.

The MBHP core module is used to read from K1 (the RAM/ROM sound patch card) and write to SD card, or read from SD card and write to IC6. This is not time critical, because during this procedure the Wavestation will be disconnected from the bus. Disconnecting (and reconnecting) it is also necessary to tell the Wavestation that a "new card" has been inserted into the (Wavestation's) card slot.

For some reasons, I WANT this to be an MBHP project.... Also, this project could easily be adapted to support other synths as well - think Roland JV/JD, whatever.

Best regards, ilmenator

WS_SRAM-card_preliminary.pdf

WS_SRAM-card_preliminary.pdf

[TK.]

Ok, it's clear now - only the bus routing is time critical, but this should work fine with the 74HC devices :)

Using discrete devices for the so called "glue logic" is the best way to go for such a project, because other solutions require special equipment (e.g. an EPROM programmer), which makes DIYing more expensive.

Best Regards, Thorsten.

[ilmenator]

After doing some searching for (DIY) programmers that can also handle GALs and PLDs on the net I would agree. It turns out that using discrete devices will result in six additional chips for all the "glue logic". The routing will be fun...

Another question would be 74HC or 74HCT? Can the outputs drive different amounts of inputs or is this the same for the two families?

Best regards, ilmenator

[stryd_one]

http://www.eng.yale.edu/ee-labs/morse/compo/logic.html

That page has some good info and a whats-compatible-with-what table which is nice. That said, I'd go for HCT because it's tolerant of various levels... What's in the WS?

Here's to glacial projects - moving slowly but unstoppable and very cool. :)

[ilmenator]

The WS sports 74HC. All cards (PCM and PROG) connect directly to chips that I would deem custom chips, though.

Thanks for the compliment  :). It's a little difficult to find time for these things between job, family life, new country of residence and all that. The project's on a boost right now (that SD card thing really motivated me, and TK's statements on MIOS support even more so), I'll see if I can keep up the pace this time.

Weren't you a fellow WS user?  ;D

Best regards, ilmenator

[stryd_one]

Right so that's CMOS levels.

The PIC pins are CMOS output and TTL input levels. Quite likely, the micros in the WS are the same, or are CMOS in and out.

The short version is: CMOS will drive TTL, but TTL will not drive CMOS.

This means you should be able to use HC. If you have problems with signal corruption, maybe try HCT... Or, use HCT at first and then try HC when it works. The only problem you'll have is data corruption, nothing should get fried.

Here have an interesting link or two

http://www.allaboutcircuits.com/vol_4/chpt_3/10.html

http://www.interfacebus.com/voltage_threshold.html

[/tilted/]

The logic you want to apply is:

Output 1: A + BD + !BC

Output 2: !A + BD + !BC

this means you only have to encode the (BD + !BC) once, which will help.

there are ways you can break this down further into only one type of chip, if need be.

[ilmenator]

So true - but actually, the requirements have changed slightly so that the truth table given above is not current anymore. But the principle of reducing and combining has become clear to me, thanks for taking your time!

Best regards, ilmenator