Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Tue, 12 Sep 2000 17:27:35 -0700, Andy Peters <"apeters <"@> n o a o [.] e d u> wrote: >File this under "Why do they do it this way?" >... >Why do they put any kind of delay mechanism into something that's >supposed to be used for functional simulations? When I do the logic >design, I'm not concerned about timing! > >-- andy I agree. The rest of this is exactly the same as a message I wrote on another thread a couple of weeks ago, but I won't let that stop me :) I'm pretty sure everything works fine if you set your sim timing resolution to ns; this is much easier than any of the other proposed fixes. This works because all the default delays in Unisims are sub-nanosecond, and so they're all truncated to zero. Only problem is, if you've got a DLL in your design, it wont lock up on a ns resolution, so you have to set ps resolution in your simulator. This is because the DLL model actually does attempt to lock up by moving its delay line tap in 100ps increments. I think this is the fundamental problem - the Unisims DLL model is basically doing a timing simulation. One fix is for the author to modify it so that it assumes that it's already locked up; I think this would be an acceptable limitation on its use. It could still carry out checks to find out if it's possible to lock. I've CC'ed the author, so we may get an official line with some luck. Whatever you do with the timing resolution, you should also set the 'TimingChecksOn' generic false on the simulator command line, or set another option to turn off timing checks (+notimingchecks in ModelSim). This'll fix the problem anyway and should make the simulation faster. EvanArticle: 25526
We are experiencing a peculiar phenomenon with a Virtex part (XCV600) which has us stumped. Initially, following configuration, all is well and the part works exactly as it should. However, a variable amount of time later (sometimes as little as a fraction of a second, sometimes as much as half an hour) the part stops working, the current drawn drops considerably (as if the clock has stopped, or there are no data transitions) and all the outputs stick at logic '0', although the DONE line remains high. Even outputs which are complementary in normal operation go low together. The time it takes before the failure occurs is very data-dependent. We can influence this period by changing the input data (digital video) from having few transitions - in which case it survives longer - to having many transitions - in which case it runs for only a short time. Cooling the chip increases the time for which it runs with a given input. All the inputs and power supplies seem to be OK, and there is good decoupling on the power rails. Once the fault has occurred the only way of restoring correct operation is to re-configure the chip. Is this effect consistent with the chip losing its configuration data, and if so why should this be happening? Are there any other stable, but non-functioning, states which can be activated by ground-bounce or other data-dependent triggers ? Richard Russell http://www.rtrussell.co.uk/Article: 25527
If you have an engineering sample of the 1804 the CF pin must be left unconnected Peter Schulz Tom Leacock schrieb in Nachricht <39BE4FFC.E100FA84@pavcal.com>... >Has anyone had any success programming the XC1804 ISP proms for Xilnx >virtex parts with the JTAG download? I am using the XC1804-pc44 proms >and multi-linx downloader, but the JTAG interface does not even >recognize the proms. >-- Thanks, >--Tom >---------------------------------------------- >Thomas Leacock >Panasonic AVC American Laboratories (PAVCAL) >311 Main Street >Westampton NJ 08060 >Phone: 609-518-3700 ext. 3218 >Fax: 609-518-3720 >email: toml@pavcal.com >----------------------------------------------Article: 25528
Thomas,
Of course I still call my company Synchronous Design! Parallel
synchronizers are simply a no-no design technique of synchronous design.
There is a whole set of rules that I use to synchronize asynchronous
signals, and parallel synchronizers is a prohibited practice. There is a
simple way around this particular problem, though.
I found out a long time ago that if I used synchronous techniques, I
don't have to do a lot of analysis and design to verify asynchronous
operation and noise abatement issues. Timing is trivialized to a few types
such as input setup and hold, register to register delays, and clock to
output delays. As technology progressed from board level SSI/MSI to
ASIC/FPGA designs, synchronous techniques became even more important, since
machines are doing most of the routing.
I once had an engineer tell me that synchronous designers aren't as
good as asynchronous designers. He was referring to the detailed analysis
that he had to do to verify that an asynchronous state machine worked
properly. I agreed with him that I didn't have to do that type of
anaylysis, and I also agreed that I was a little rusty in that department.
Three years later his design started failing out in the field. He had
failed to analyze his design sufficiently to accommodate wear and tear on
the transistors over the years.
This does not mean that I will not pay attention to asynchronous
design, though. Technology changes rapidly in a few years to where I have
to pay attention to anything related to our field of expertise. In fact,
there is a company here in town called Theseus Logic that specializes in
clockless logic. They have a lot of funding, so someone thinks that this
technology is worth a shot. I have not investigated it, because I am very
busy, but I will soon just to find out what they are doing. Maybe I can
learn something that I can apply to what I am doing. They have white papers
on their web site if anyone cares to indulge.
I hope I have answered your question sufficiently for you to understand
why Sychronous Design is alive and well.
-Simon Ramirez, Consultant
-Sychronous Design, Inc.
"Thomas Falk " <falk@iee.et.tu-dresden.de> wrote in message
news:8pn9uu$bd4$1@rks1.urz.tu-dresden.de...
> Hi Simon,
>
> thanks for your answer. In my case the parallel input works fortunately,
> but some of the logik detecting slopes in slow impulse trains does fail.
>
> Interestingly enough, there seems to be a lot of experiences in this
> group with similar problems, but I haven't heard anything from XILINX yet.
>
> Thanks,
>
> Thomas
>
> PS: Simon, despite your experiences with synchronizers you call your
> company still Synchronous Design ? ;-)
>
>
Article: 25529"Mark Harvey" <mark.harvey@iol.it> wrote in message news:EjCv5.16916$Sm1.265203@news.infostrada.it... > The rep in my area certainly doesn't lack any balls! --I am glad. What is her name? > Again, if the disti has been dishonest or exaggerated his/her tech support, > then they deserve to be put in their place. --This happens a lot. All it takes is lost sales. > > --I agree with you here 100%. I bet that if Andy, the original poster, had > > a darn good Xilinx specific disty FAE, he wouldn't have the problem he is > > having. His problem (my opinion) is that the disties are asking him a lot > > of questions, contributing nothing to his cause, wasting his time, and > they are still getting the registration! > > But somebody, somewhere HAS to register the design. --Yes and no. That somebody is the Xilinx FAE, but we're not talking about him, we're talking about disties. A disty does not need to be involved, i.e., register a design, every time. Just ask the direct accounts. -Simon Ramirez, Consultant Synchronous Design, Inc.Article: 25530
wath software can I use to program 16v8 and 22v10 ???Article: 25531
In article <39BF49EB.4A5D@designtools.co.nz>, Jim Granville <jim.granville@designtools.co.nz> writes: > Can you clarify 'slopes in slow inpulse trains' - are these slow edges, > and how many registers do they feed ? Hi Jim, Exuse my English, I meaned the edges of impulses. In my case the output of a D-FF was feed into the D input of another one and from this I wanted to detect the edge by a logic combination of input and output of the second D-FF. The timing simulation showed that in my case the change of the data arrived earlier than the corresponding clock edge. The clock came via a global net GCK1. ThomasArticle: 25532
Well, it has been working for me. Virtually all of my designs are a mix of structural (instantiated) and RTL code. I tried setting the simulator resolution to get around it, but that kept the DLLs from working. Setting the generics seems to do the trick. Why it defaults to On for a library that is ostensibly for FUNCTIONAL simulation is beyond me. "K. Orthner" wrote: > > Ray, > > You mean I didn't have to go recompile the unisim libraries? It's as easy > as setting the generic to FALSE? Then all the nasty timing ptoblems go > away? > > ray@andraka.com (Ray Andraka) wrote in <39BF2224.8921F01@andraka.com>: > > >I also ran into the same thing. When you instantiate the clocked unisim > >components, set the TimingChecksOn generic to "FALSE" to disable the > >timing crap. You'll also have to surround the generic in the > >declaration with syn_translate on and off pragmas to keep the synthesis > >from complaining. For example: -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25533
Michael Warner wrote: > ster should be sufficient. > > Yes, they are, and that approach did occur to me. Would it be simpler > than 64 simple ripple counters? Yikes, no! use synchronous counters. With the carry chain it takes up the same area and everything runs off a common clock -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25534
I don't know hom much you will find in the literature about multiplied clocks in this context. Just use a master clock that is say 16x your data rate. Of every 16 clock cycles, one is dedicated for processing a particular channel. That allows you to share the accumulator over many channels, The intermediate strage for each channel should then be kept in a small synchronous RAM instead of individual registers. The RAM address is the 'time slot'. ALternatively, you can use a shift register in place of the RAM. Michael Warner wrote: > > On Tue, 12 Sep 2000 11:59:31 GMT, Ray Andraka <ray@andraka.com> wrote: > > >what is the available clock and required sample rate? If you can supply a > >multiplied clock, you can reduce the size of the logic substantially. > > It's pretty slow - the PWM time-slice is probably no less than 1us. > I'll have to read up on these "multiplied clocks", since they seem to > be the key to success :-) > > Thanks for your help, folks! -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25535
"psisabel" <psisabel@mii.zaz.com.br> wrote: > Somebody would have a schematic of memory ram or > salary so that I can accomplish a project Salary? Do you mean cache? Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25536
erika_uk@my-deja.com wrote: > why virtex chips are rectangular and not square My guess is because the BlockRam takes up several columns which, if filled with CLBs would make it square. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25537
An update after wasting yet another day with this. After reading about some other XC95xxx problems on this NG someone mentioned moving optimizing method and things working.. So After extensive playing I found that if either "use timing optimization" or "Using MultiLevel Optimization" were checked my ABEL Script failed miserably. Changing other settings (like PTERM limit) only changed how the symptoms looked. Problem is I changed from almost fitting in one size down (9572) to barely fitting in what I am using (95108) which scares me incase I have to add to the design as there is no drop in package one size up for me. Interestingly I have ALWAYS found that Using MultiLevel Optimization makes the design take more equations, not less which seems odd. So any thoughts on this. Is this Foundation screwing up or am I implementing my ABEL BCD-7 SEG LCD driver incorrectly? Thanx RickArticle: 25538
Darn Language Translators I bet.. Good catch.. I had been scratching my head trying to figure out what he meant. Cache=cash=Salary I didn't get that far. I was trying to figure out if he was asking how much it would cost in Salary to get someone to do this part of his "project". Anyway psisabel: You'll have to give us more info on what you want as I am not clear.. Are you looking for a schematic of how traditional memory is implemented on a logic level or do you have something more specific in mind or what exactly are you after. Hawker husby@my-deja.com wrote: > > "psisabel" <psisabel@mii.zaz.com.br> wrote: > > Somebody would have a schematic of memory ram or > > salary so that I can accomplish a project > > Salary? Do you mean cache? >Article: 25539
Are you going into some sort of boundary scan mode? I had a similar problem with a XCS05. I found some sort of app note about adding some pull-ups and 2 small caps to the JTAG pins and it fixed the problem. Basically random noise was putting me an a boundary scan or JTAG programing mode of some sort Can't remember what exactly it was as it is now a block in PADS-PCB/Logic that I just plop down that gives me all the parts I need for JTAG (header, caps, resistor etc) so I have long forgotten the exacts.. but can look up if needed. HawkerArticle: 25540
"K. Orthner" wrote: > > Ray, > > You mean I didn't have to go recompile the unisim libraries? It's as easy > as setting the generic to FALSE? Then all the nasty timing ptoblems go > away? No, TimingChecksOn = FALSE disables the setup/hold/etc tests. The delays are still there. > ray@andraka.com (Ray Andraka) wrote in <39BF2224.8921F01@andraka.com>: > > >I also ran into the same thing. When you instantiate the clocked unisim > >components, set the TimingChecksOn generic to "FALSE" to disable the > >timing crap. You'll also have to surround the generic in the > >declaration with syn_translate on and off pragmas to keep the synthesis > >from complaining. For example: -- ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25541
eml@riverside-machines.com.NOSPAM wrote: > > On Tue, 12 Sep 2000 17:27:35 -0700, Andy Peters <"apeters <"@> n o a o > [.] e d u> wrote: > > >File this under "Why do they do it this way?" > >... > >Why do they put any kind of delay mechanism into something that's > >supposed to be used for functional simulations? When I do the logic > >design, I'm not concerned about timing! > > > >-- andy > I agree. The rest of this is exactly the same as a message I wrote on > another thread a couple of weeks ago, but I won't let that stop me :) No, no, don't stop! > I'm pretty sure everything works fine if you set your sim timing > resolution to ns; this is much easier than any of the other proposed > fixes. This works because all the default delays in Unisims are > sub-nanosecond, and so they're all truncated to zero. That's a good idea. My test benches all have a generic that sets clock speed, which is arbitrary in a functional simulation, anyway. > Only problem is, if you've got a DLL in your design, it wont lock up Nope, no DLL yet. Unless the design isn't fast enough for a Spartan, in which case it'll go to a Virtex. I'm still in the "conceptual design" stage and trying various solutions before I commit to anything. Or before they commit me. > Whatever you do with the timing resolution, you should also set the > 'TimingChecksOn' generic false on the simulator command line, or set > another option to turn off timing checks (+notimingchecks in > ModelSim). This'll fix the problem anyway and should make the > simulation faster. Does that affect the 100 ps prop delays, too (assuming ps resolution)? I think those are still there. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25542
eml@riverside-machines.com.NOSPAM wrote: > I'm pretty sure everything works fine if you set your sim timing > resolution to ns; this is much easier than any of the other proposed > fixes. This works because all the default delays in Unisims are > sub-nanosecond, and so they're all truncated to zero. Ah! Just did the test. Simulation resolution set to ps (which was my default, since my last design ran at 80 MHz which requires ps resolution to deal with 12.5 ns) and everything's screwed up. (By screwed up, I mean that my state machine is off by one tick, and not grabbing data when it's supposed to.) Set resolution to ns, problem solved. On 2/2/2000, someone with the initials SG at Xilinx changed the default for DefaultTimingChecksOn to false, so timing checks aren't being peformed. I had opened a Xilinx case about this, and I just discussed it with the apps guy, so there should be a Xilinx "Answer Record" about this soon. I told him that I still didn't think a functional model should have any kind of timing information in it, and he agreed. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25543
Thomas,
There is an easy way to do what you describe below. I call it digital
differentiation, where the job is to detect an edge, leading or otherwise.
All you have to do is create a process that delays the signal A by one
clock cycle. Assuming signal_A is active high, this is easy to do:
signal_A_delayed <= signal_A;
Then you simply do the following to create a combinatorial pulse
(signal_A_diff) that is generated at the edge:
assign signal_A_diff = signal_A & ~signal_A_delayed; // detect
rising edge
assign signal_A_diff = ~signal_A & signal_A_Delayed; // detect
falling edge
Assuming that you are doing the above, I see no reason why you should
have any problem with timing. signal_A_diff is a combinatorial signal that
is generated to be used by other flip flops, and its prop delay is part of
the timing between flip flops in a Xilinx net PERIOD constraint. Thus the
whole design is still synchronous.
Do you have any causal signals that are going to resets or presets of
flip flops?
-Simon Ramirez, Consultant
-Synchronous Design, Inc.
> Hi Jim,
>
> Exuse my English, I meaned the edges of impulses. In my case the output
> of a D-FF was feed into the D input of another one and from this I wanted
> to detect the edge by a logic combination of input and output of the
second
> D-FF.
>
> The timing simulation showed that in my case the change of the data
arrived
> earlier than the corresponding clock edge. The clock came via a global net
> GCK1.
>
> Thomas
>
Article: 25544
Richard,
Are you sure that ALL of your inputs are defined? If you have a
floating input, especially a control pin, it could cause weird problems.
Data dependent noise could then activate some function that causes the
symptoms described below.
-Simon Ramirez, Consultant
-Synchronous Design, Inc.
<news@rtrussell.co.uk> wrote in message
news:8pnntc$2jt$1@nntp0.reith.bbc.co.uk...
> We are experiencing a peculiar phenomenon with a Virtex
> part (XCV600) which has us stumped. Initially,
> following configuration, all is well and the part works
> exactly as it should. However, a variable amount of
> time later (sometimes as little as a fraction of a
> second, sometimes as much as half an hour) the part
> stops working, the current drawn drops considerably
> (as if the clock has stopped, or there are no data
> transitions) and all the outputs stick at logic '0',
> although the DONE line remains high. Even outputs
> which are complementary in normal operation go low
> together.
>
> The time it takes before the failure occurs is very
> data-dependent. We can influence this period by
> changing the input data (digital video) from having
> few transitions - in which case it survives longer -
> to having many transitions - in which case it runs
> for only a short time. Cooling the chip increases
> the time for which it runs with a given input.
>
> All the inputs and power supplies seem to be OK, and
> there is good decoupling on the power rails. Once the
> fault has occurred the only way of restoring correct
> operation is to re-configure the chip. Is this effect
> consistent with the chip losing its configuration data,
> and if so why should this be happening? Are there any
> other stable, but non-functioning, states which can
> be activated by ground-bounce or other data-dependent
> triggers ?
>
> Richard Russell
> http://www.rtrussell.co.uk/
>
Article: 25545Nope, block RAM is, at least conceptually, along the shorter dimension. husby@my-deja.com wrote: > > erika_uk@my-deja.com wrote: > > why virtex chips are rectangular and not square > > My guess is because the BlockRam takes up several columns > which, if filled with CLBs would make it square. > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25546
On Wed, 13 Sep 2000 10:41:27 -0700, Andy Peters <"apeters <"@> n o a o
[.] e d u> wrote:
>eml@riverside-machines.com.NOSPAM wrote:
>> Whatever you do with the timing resolution, you should also set the
>> 'TimingChecksOn' generic false on the simulator command line, or set
>> another option to turn off timing checks (+notimingchecks in
>> ModelSim). This'll fix the problem anyway and should make the
>> simulation faster.
>
>Does that affect the 100 ps prop delays, too (assuming ps resolution)?
>I think those are still there.
>-- a
>----------------------------
>Andy Peters
You're right, it doesn't affect them. I've just checked and just about
everything of any interest in the library has these delays. So, the
question is, are there any circumstances in which addition of an
arbitrary 100ps delay will screw up a functional sim? I can only think
of two:
1) If you instantiate lots of unisims components in a chain, such that
the cumulative 100ps delays add up to more than a clock period, then
the sim will fall over. Unlikely, but possible.
2) More interesting: the Unisim clock elements (IBUFG/BUFG) also have
the default 100ps delay. If you're into coding guidelines, you'll know
that you shouldn't put a delta delay on a clock by doing something
like
CLKA <= CLKB
because of the potential for races. This is similar, just much worse -
in fact, it's plain wrong, Mr. Patel, if you're reading this. However,
you can still get around this without modifying the libraries. There
are two problem cases - one for IBUFG, one for BUFG.
(a)
Device Under Test: IBUFG on an input clock, RTL code for the sampled
data
Testbench: Stimulus is produced with zero delay from the clock, and
the stimulus data is resampled in the device by the clock
This is a problem, since the IBUFG delays the clock, but the input
data isn't delayed (because no Unisim component is instantiated),
hence isn't resampled correctly. To fix this, just change your
stimulus-generation code in the testbench to reflect the real setup
and hold you're going to give the device, instead of just doing
zero-delay stimulus. This is much better anyway, since it allows you
to use the same testbench for both functional and timing sims.
This looks something like this:
-- enter loop HOLD_IN after a clock edge
while not STOP_SIM loop
wait for PERIOD - SETUP_IN - HOLD_IN;
-- reached the setup point: read file, or whatever,
-- and drive stimulus
...
stimulus <= ...;
-- deschedule, drive the stimulus, wake up at the next clock edge
wait for SETUP_IN;
wait for HOLD_IN;
stimulus <= (others => 'X'); -- or whatever
end loop;
wait; -- end of sim
(b) second case - instantiating BUFG directly in your code, driving it
from an internal signal. Something like CLKA -> combinatorial logic ->
CLKB. I don't think that there's a problem here, since the RTL code is
presumably not going to try pass signals from domain A to domain B on
the same clock edge, which would just be wrong.
So, here's some modified take-it-or-leave-it advice for functional
sims:
(1) Don't mess with the libraries
(2) Turn off timing checks anyway, using a generic on the sim command
line or a specific simulator switch. Not necessary for ns resolution,
but will give a faster sim.
(3) If you can use ns resolution, then you won't have a problem
(4) If you have a DLL, then you must use ps resolution
(5) If you must have ps resolution, then:
(a) make sure you have turned off timing checks
(b) In your testbench, don't use zero-delay assignments: use a style
that will be correct for timing sims
Evan
Article: 25547Thomas Falk wrote: > In article <39BF49EB.4A5D@designtools.co.nz>, > Jim Granville <jim.granville@designtools.co.nz> writes: > > Can you clarify 'slopes in slow inpulse trains' - are these slow edges, > > and how many registers do they feed ? > > Hi Jim, > > Exuse my English, I meaned the edges of impulses. In my case the output > of a D-FF was feed into the D input of another one and from this I wanted > to detect the edge by a logic combination of input and output of the second > D-FF. > > The timing simulation showed that in my case the change of the data arrived > earlier than the corresponding clock edge. The clock came via a global net > GCK1. > > Thomas I'm not sure if this is right but I've just been looking at the SDF file produced by the tsim -> ngd2ver chain. For a -7 XC9572 it shows in the very simple case of a FF that just produces a delayed version of the input: Delay on input = 2.5 ns. Global clock delay = 1.5ns FF setup/hold at its clock pin = 1.5/3.0 Therefore the global timing of the input wrt the clock pin is 2.5/2.0 whereas the data sheet gives something like 6.5/0. Is CPLD timing simulation to be trusted ? I thought Xilinx, like all silicon makers, work very hard to make sure that their FFs have 0 hold time or at least that the min Tco > Thld. For ASICs this means this means that to get post layout hold times o.k. you only have to deal with the small amount of clock skew introduced by the clock trees.Article: 25548
On Wed, 13 Sep 2000 11:19:20 -0700, Andy Peters <"apeters <"@> n o a o [.] e d u> wrote: >Ah! Just did the test. Simulation resolution set to ps (which was my >default, since my last design ran at 80 MHz which requires ps resolution >to deal with 12.5 ns) and everything's screwed up. (By screwed up, I >mean that my state machine is off by one tick, and not grabbing data >when it's supposed to.) > >Set resolution to ns, problem solved. Almost forgot - technically, it's illegal to run the sim with ns resolution, since the library contains ps delays (LRM 3.1.3.1). However, I suspect that most simulators can cope with this. EvanArticle: 25549
"S. Ramirez" wrote: > Richard, > Are you sure that ALL of your inputs are defined? If you have a > floating input, especially a control pin, it could cause weird problems. > Data dependent noise could then activate some function that causes the > symptoms described below. > -Simon Ramirez, Consultant > -Synchronous Design, Inc. I think its more likely the new ``cycle based'' licensing scheme whereby any design is only allow to run for a certain number of clocks before maintenance becomes due. You will however still be able to re-use or develop any of the logic transitions generated from your clock allocation.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z