digital logic library by 74xxxx part number?

You certainly can with Altera Quartus.

Slurp

If Xilinx won't do it,

what schematic capture will, and it has to output SCH filetype or other Xilinx compatible schematic format.

Rich

Perhaps you can find an earlier version of ISE, say, v5.1, which may, in fact, be the last version that supported functions like that, and the fidelity of reproduction of TTL functions is not 100%, BTW, you can do that with CPLD designs. The TTL components went away in FPGA libraries a release earlier than for CPLD's. The schematic package, ECS, leaves a bit to be desired anyway. It doesn't align components very well, selects components if you click anywhere near them, frequently scrambles your carefully laid-out wires, etc. It also freuquently does stuff you want quite backwards, e.g. numbers signal names in the opposite order from what you told it, but only sometimes, and sometimes requires you to exit the drawing package before it will accept your drawing. A little prune juice, and a lot of whiskey will help a little.

Richard

Hi Rich, in the older Webpacks (ISE 4.2, maybe even 5.x) was a small TTL library available for CPLDs only. Maybe you can access it by the ISE-Classic programms if you have no acess to the older Webpacks.

It surely can be converted to FPGAs.

But do you really need it?

The symbol INV is an Inverter , is called an inverter, and is the only single Inverter.

Why use multiple names for the same thing (e.g. 74xx04, 74xx05,74xx14,

74xx4049). All Inverters, some with special features that may be unused inside a programmable chip.

Why drawing more than nessecary? AND2b1 and its companions gives you inverted inputs without pushing symbols around. INV4 etc. work on whole busses without need to name every line.

The MSI functions don't have all the excessive I/Os that are often unused or abused for "tricks". Designing with the pure functions gives you better results. Some old chips can hardly be reimplemented in CPLDs or FPGAs. Look for

74ls193 in the forums.

Time is better spent on rethinking the old design, or even learn a HDL than reimplementing libraries for obsolete components.

From your former post I know that you would prefer to do nearly nothing to reimplement your old TTL schematic into actual devices (OSR :-) ) but be sure, it won't work that way. Every beginners pitfall is waiting for you. (multiple and gated clocks, asynchronous and gate delay designs and many more)

have a nice synthesis Eilert

For the most part, I'm right with you on your comments. However ... ... there's always a however ... sometimes someone hands you a schematic and says, "THIS is what I want, and THIS is what I'll pay you to recreate in programmable logic," and that's where the fun begins. I've had little trouble getting "transcriptions" of SSI/MSI designs to work in CPLD's, with the exception of one-shots, which can, but shouldn't, be implemented in CPLD's with SCHMITT inputs. However, some "TTL" library parts didn't work quite right when taken directly from the XILINX library, and some had extra or omitted signals, the justification for which was seldom available.

If someone wants THIS generated in CPLD/FPGA hardware, you have to give it your best effort, but if you do it in HDL, it's unlikely anybody will be able to review it to their satisfaction. If you present a 100 modules of VHDL to a group of guys my age, who went to college when transistor radios were just becoming commonplace, all you'll get is "what's this?" and maybe fired, unless, say, you can plug our device in an application for what you've got to replace, and demonstrate it works as well as the original.

Reviews are a problem. If you have a well-designed, well-documented, fully verified logic design implemented on a device that's working to your satisfaction, you still have to go through the review process. If the senior engineers, and I don't mean those kids who don't even remember back before there was a NASA, are presented with a single-page schematic, they can grasp what's going on in the design, at least to their own satisfaction, with the help of the documentation, in about a half an hour. If you hand them a stack of HDL listings, and especially if you've presented them with a block diagram that represents a bunch of HDL-implemented blocks, you're in for a rough ride, and a week of being raked over the coals, at great expense to someone, since all that engineering horsepower has to be paid, and the buy who signs their checks probably signs yours, too. If you show them a schematic, they know what it means and can interpret it as well as they need. If you substitute synchronous for asynchronous logic, they'll understand why you did that. Support it with block schematics and simulations and they'll bite. If you support it with HDL blocks and simulations, they'll fight. You'll be accused of bait-and-switching on them.

That, BTW, is why I'm so upset over the fact that both XILINX and ALTERA have made their schematic capture software a distant, neglected, and indadequately documented stepchild.

Richard

Good luck fitting a modern design on a single schematic sheet. Unless, of course, that sheet is Z size, or whatever.

Seems to me that Altera and Xilinx (and Lattice, and Actel and QuickLogic) are putting their efforts where it's needed (and wanted), which is to say in better synthesis tools.

-a

There is an older generation of designers (my generation) who grew up thinking in terms of the 7400 data book: 74161, 74138, etc create instant associations. But we must all realize: those designs were created between 1968 and 1971, i.e. more than 35 years ago, when designers at Fairchild (I was one of them) and T.I. defined practical logic blocks that fit into a 16-pin package, and could be interconnected with a minimum of extra "junk", like inverters. Those "rules of the games" have changed drastically. 16-pin packages have become 300- to 1400-pin packages, inverters have evaporated in the LUT structures... Apparently we did too good a job of indoctrinating the logic designers to think in terms of MSI functions. But remember, this was created for your father's or even grandfather's generation. 35 years is an eternity in this business. Keep thinking in terms of functionality, draw block diagrams, but leave the gory details to the synthesizers. R.I.P. 7400 ! Peter Alfke, Xilinx Applications

Indeed. Some EE professors are still teaching this abstraction level.

Yes. Even some of the newer generation seem convinced that FPGAs are full of little counters, shifters and adders that just waiting to be wired up.

Well said. Thanks for the posting.

-- Mike Treseler

On a sunny day (Mon, 13 Feb 2006 16:29:50 -0800) it happened Mike Treseler wrote in :

whots wrong with SLRs?

That's the way a newbie would go about it. I exclusively use 'schematic' (Quartus) for all my fpga work. I have been designing digital processing systems all my working life (since 1968) and using CPLD/FPGA since around

1987.

I do not design micky mouse systems either - am involved in design of massively parallel image processing systems all the time.

Best way is to create a hierachical design from the bottom up - I may use 1 sheet for perhaps a feature extractor for example, design for the target device, create test benches and thoroughly test, then create a symbol for that function. That function can then be used as many times as you like at higher levels of the design. The top level design brings together all the tested sub functions.

Its easy to see whats going on.

Before any of you VHDL guys start shouting - ahhh but its much quicker using a description language I will say that most of my designs work first time - and I have always got there much faster than any guy writting high level in any language - and with a fully documented, easily modified design.

Designing at schematic level does NOT necessarily mean gate/counter level either, a single component may easily be a complex processing function.

Slurp

Slurp, I like your approach, but I think you really have to start with a top-level block diagram that describes how you intend to solve the overall problem. Then you solve it in chunks, from the bottom up... I think age and experience strongly influences these choices... Peter Alfke

No parallel port?

The software guys have been having religious wars over top-down vs bottom-up ever since I first enountered either term.

My vote is to work on the hard part. If you think you understand the overall data flow but aren't sure how to make some chunk go fast enough, then start working on that "bottom" level chunk. If all the bottom chunks look easy, then make sure you understand the high level.

The truly amazing performance gains are usually the result of algorithim changes. Consider FFT vs the old slow way. Consider hashing vs searching a long list.

On the other hand, lots of times, a factor of 2 in some low level chunk can make or break a project.

Is counting IO pins, CLBs, BRAMs or ... top or bottom?

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:>

Not trying to get into religious wars... I think it is top level. I start with a basic outline what I want to achieve ("if you don't know where you want to go, every way is a right one"), then check up on required resources, like clocks, pins, RAM etc. Then go to the bottom and crack the toughest nut, for it will most likely determine the fate of the whole design... The beauty with programmable logic is that we can design the pc-board while a large part of the design is still unfinished. Of course, we all know (and love) that.

Peter Alfke

7400 a good way to learn digital electronics, there are many CHEAP books available on the subject. This is for a hobby, not a job.

I learned with these chips, looking at old schematics and books.

Can anyone reccomend a text that will be good for transisiton between 7400 and VHDL ?

Rich

To be honest, I don't use HDLs because they are "faster" than schematics.

I use them because I can create comprehensive test benches to simulate and verify my design before it's committed to the PCB. My test benches include models of the other devices on the board -- memories, processors, whatever.

I find that debugging the real hardware is a lot easier when I've simulated the design. And if I do find a bug in the hardware, I recreate the bug in the simulation, which simplifies fixing the bug.

A bonus is that with an HDL, I can take advantage of source-code control tools such as subversion. What changed between this version and that? Let's check the log. Oh, yeah, that; now let's diff the old code and the new code to see exactly how this changed.

I suppose another bonus is that you're not hung out to dry when your FPGA vendor decides to change the schematic formats.

-a

Here are some examples to get you started:

-- Mike Treseler