Thanks for the great help offered by the group to our FPGA issues. This time the queries are:
1) I am planning to use a LM317(National Semi) Regulator to power my board having Spartan2 XC2S150 and some other TTL Ics. Would this regulator be able to provide the required POS current [power on surge current] for the FPGA? What current rating is recommended? 2A or more? If this is not good, which regulator would be OK?
2)I have a 20MHz clock in my design that is used in some flip flops in the design. Most of the circuit is combinational and with about 18 combinational clocks. What bypass capacitor ratings would be OK for my design .01uf would be OK?
3)In XST 5.1i , there is a synthesis option which says "Add I/O buffers". Does that mean that if i check this option, the XST would automatically insert I/O buffers[IBUF,OBUF,IBUFG,OBUFT etc] into my top-level module ports and i don't have to instantiate these I/O buffers into my HDL code?
LM317 is fine, but is kind old style the rating depends on the voltage drop on regulator if the incoming voltage is low then you can use some nice regulators in SOT223 package they are sufficient (but will get a little hot/warm) with LDO regulators check the special required bypass caps!
I use always 0.1 there is not much difference in size or prics its 0603 package always
1) the LM317 meet sthe datasheet requirements (current and current limiting)
2) use 0.1uF caps. surface mount 0402, or 0406. One each for every power and ground pin pair. X7R material. Keep inductance down to min. Read th SI Central web pages on power distribution systems.
That is a scary statement. Are you really using 18 clocks driven by combinatorial logic? You must be either very inexperienced, very brave, or very smart. Or perhaps all three. Normal humans stay away from such design methodologies, and use synchronous logic with a minimum of global clocks (preferrably only one). That's better for your health, your sleep, and your sanity... Peter Alfke
Well, he's certainly using the right (read ONLY) architecture that will do it. I got started with Xilinx on a project where I needed 72 flip-flops on a board, all essentially asynchronous from any other. (This was a timing and logic controller for nuclear detector applications). Xilinx was the ONLY architecture that could handle lots of acynchronous clocks at the time. It may still be. There certainly can be complications with things like this.
We needed to have totally asynchronous timing, with resolution below 1 nS, so no global clock could do it. We used the AD9201 timing chip to handle the time delays, but that chip lacks a FF to make it into a one-shot function, which was what we needed.
Thanks for pointing out the issue. You are right about the synchronous clock issue. I know its not good to use asynchronous designs, but i have a different problem at hand. I am actually doing reverse engineering of a board made in probably 1980. It has more than 200 I/Os and over 180 TTL ICs. I have a rough schematic of it and no other info. So, I thought it wouldn't be practical to start tracing the boards functionality and make it SYNCHRONOUS ...and it may never be possible i feel...so i had to go with combinatorial clocks which the design is already using..
Now i know synchronous design has its advantages, but does that mean that asynchronous design will never work..in discrete ICs or in FPGA? Please comment..
Make sure there are no reports of "flakiness" with the old design.
But say we assume that the TTL designers got it right, and that all of the logic races were skewed in the right direction for reliable operation.
Now you change from TTL to cmos/FPGA and a new set of races are on. I expect that the time you save by skipping a redesign will be more that used up by debugging logic races.
An asynchronous design can work, but it is *very* difficult to prove that that it will always work over time and environment. Even the simplest case of building a reliable d-flop primitive is non-trivial.
It a simple task to prove reliablility on a synchronous design.
I remember the 70's well. :-) The TTL logic we used was slow by today's standards, with output delays of 25 ns and gentle rise and fall times. But the interconnect was fast, just wires, at 1 to 2 ns per foot.
Now, in FPGAs, you have very fast logic, with extremely short transition times of
Hi Rider, As others have said, you'll probably find 2) quite tricky. Why not synchronously clock the whole thing a lot faster, say 100MHz, and make synchronous models of the slow logic and FFs? This way you overcome the hideous skew problems? The old TTL switches slowly so any
10ns latency due to the 100MHz clock won't matter. Modern FPGAs have many orders of magnitude more logic than TTL so the extra gates aren't a problem. Just an idea, Syms.
Thanks for everyone for comments on my design. All those comments are scaring me . So please help me out in this situation. I try to explain the design a bit.
As i told, the design has around 200+ IO's with more than 80 inputs and nearly 180 ICs. No information on these inputs is avaialble apart from their connections, from the schematic. There are around 24 Flip flops (D and JK type) and few other ICs requiring clocks. We have an on board clock of 20Mhz which is clocking some of FFs, while some are clocked from external port inputs and some from Combinatorial clocks. The design is clearly Asynchronous. Also due to non-avaialability of information about IOs, i cant trace the design functionality(due to massive nets). What i have done is modeled the possible ICS in Verilog and instantiated them as per schematic. the few observations are:
1)Some FFs have their inputs permanently tied to 1 or 0. (OK i feel?)
2)Some FFs share common clock but their inputs are combinational logic comprised of other FFs(same clock). (Its OK i guess).
3)Here seems a problem: A FF is clocked by local 20MHz clock, but its input is a combinational logic which itself derives it inputs from outputs of FFs clocked by signals from 2 external ports. (Clearly Asynchronous. So why did the designer use it? How could he have been sure at that time that their is no asynchronous effect?)
4)An input from IO port passes through a buffer IC . This buffer's output makes input to a clocked IC, which is inturn clocked by a combinatorial logic. Again asynchronous.
The card is authentic and from a reliable company. My question is that wasn't there any concern at that time(1980) of asynchronous design that the designer has used so much asynchronous techniques? Is it possible that there is no such REQUIREMENT of synchronism in this design(the system interfacing to IOs of card can handle it ? of which we have no knowledge). Isn't asynchronous design a necessasity times when either synchronous design is neither possible nor feasible? Also why i am gonna be in trouble? Because i am shifting to FPGA OR theere would be same problems even if i redesign the card with same components it is now using? If FPGA is a problem, then why do they claim that we can translate our obselete components into FPGA? If a design is asynchronous inherently, should we forcibly synchronise it mere for the sake of FPGA implemenatation?
Sounds like the board synchronizes incoming data+clock to one system clock. Maybe there is som metastability improvmenet technique incorporated.
Do the FF IC:s have clock enable? If not, that could be done by using combinatorial clocks.
Is there much feedback between all the FF:s? If so, I guess there is some state machine in there (scary...), if not then I'm sure it's relatively easy to reverse engineer the board.
What's the board'sfunction, anyway? That would give you a good start.
Homann
--
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se
Do you have the schematics? If so, look for the standard clock-qualifier pattern. The clock will run into one side of an '00 and the qualifying signal will run into the other side. The output is a qualified clock. It will look like an asynchronous clock to the FPGA tools, but it really was synchronous in the designer's mind.
This was used because chips like a '374 didn't have a clock qualifing input pin.
A common clock distribution scheme in the old TTL days was that the master clock from the osc clocked a FF to square things up and the output of the FF then fanned out to several buffers and they went to another layer of '00s which were buffers and qualifiers. Allways running clocks went through a dummy '00 to balance the skew (and get the polarity right).
You could also get similar qualified clocks out of a '138 or '139 by feeding the clock into the enable pin. This gets you 1 of N decoding for things like writing to 1 of several chips. The skew wasn't as well balanced but it generally worked well enough.
Note that all of the '00s used in the clock distribution chain were the same technology - no mixing LS and F as that would mess up the clock skew.
--
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.
I'm curious -- why do you believe that "ONLY" Xilinx architectures will work for "asynchronous" clocks? I know the Stratix/Cyclone families of Altera very well, and cannot see why they cannot handle such designs. I am also hard-pressed to figure out where the defficiency is in APEX/FLEX too, though I am less familiar with them.
One thing I'd like to point out is that Stratix (when I compare to Virtex-II) has significantly more global clocking available. There are 16 global clocks (8 to each quadrant) in Virtex II, while Stratix has 16 truely global clocks, plus 16 quadrant clocks (4 per quadrant) and 2 quadrant/octant fast clocks. In a 1S80 device, this means there are a total of 48 independent clocks available to you. What does this mean? You're less likely to have to rely on locally routed clocks or other such things that make getting a design right that much harder.
You forgot that we also have dedicated clocks to deal with the clock domains from high-speed IOs, which are localized around the IOs and the dedicated serialization / deserialization hardware we have for high-speed LVDS. There are 16 extra dedicated clocking resources around the IOs for this, giving a total of 64 independent clocks on dedicated resources in a 1S80.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.