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
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:b3j0u313cagi92a8lih356oriesvtsb46e@4ax.com... > On Tue, 18 Mar 2008 23:08:18 GMT, "KJ" wrote: > >>dbg_state <= std_logic_vector(to_unsigned(STATE_TYPE'pos(state), 3)); > > Very nice, but in the past we have had trouble with some synthesis > tools not implementing 'pos and 'val. Does anyone know the > current state of play? 'pos and 'val both work with Quartus, I'm pretty sure it works ISE and Synplify as well (or at least I don't remember opening any service requests to X and S about them not working). I do seem to recall having a problem with 'succ with either ISE or Synplify, not sure which one and not sure what the state of that service request is. In any case, a problem with 'succ is not a problem with 'pos or 'val. > I know of several tools that *do* > support it, but haven't done a thorough check recently. And apparently you don't want to name the several tools that you know that do support it even while asking others for that same info ;) Kevin JenningsArticle: 130251
Daniel wrote: > Yes, I have a clock on that pin too. Why do you ask? Because these are primary and secondary clocks of a pair, and therefore they share resources. And that is what this message is trying to tell you: "The main restriction on clock placement is that only one clock output signal for any Primary / Secondary pair of clocks may enter any region". If you spread your clocks out so that you are only using one of each primary / secondary pair, and you have 8 clocks or less, then you would not have a problem. > This IP interacts > with many components: rocketIO, SDRAM, ZBTRam, PCI bus and DACs; and > that is why, I think, it uses so many clocks. I thougth I was runing > out of clocks resources so that using IBUFG I was saving some. The > problem is that as the logic grows, even using IBUFG, P&R is unable to > route the hole design and I get the ERROR:Place:249. Nope, ibufgs won't save resources, because it is actually using a bufgmux, just like a bufg. Different routings can result in failure/ non failure dependent upon the how PAR places components, because physical routing resources are divided into 4 quadrants. Yes, I think you are running out of resources, but it may only be because you are using both the primary / secondary clock of a pair. > Because my part of the logic on the FPGA generates the signals to > enable DACs which move with an external clock, I generated them with > system clock and put 3 synchronizers runing at external clock to sync > them with it. I mean, reduce as much as possible the part that should > use the external clock. I think you are going to find that in this application, using 3 synchronizers instead of 1 does not buy you anything. With 1 synchronizer, you don't need to bother with a global buffer for the external clock input. Just place timing specifications that insure that the external clock pin input to registered output pin to the DAC is small enough to meet the setup time the DAC requires. For even a modestly fast DAC, this should be easy to meet.Article: 130252
1>The Power Management Capability of PCIE can be removed? Is it option or necessary? My PCIE-based GbE controller reports NMI error after ifup command. Uhhuh. NMI received for unknown reason 20 on CPU 0. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue I suspect the Power Management issue? 2>How to deal with the PCIE across 4K boundry issue? Assumption: Max Payload size=256 bytes,DMA base addr=0xc41000,DMA Burst size=32bytes,packet size:64~1536 bytes,datawidth=32bit my understand:The current DMA burst cann't across the 0x1000 address. it must break the current DMA at 0xFFC,and restart the remain DMA data from 0x1000. is it? 3>16bit PCIE wrapper of GTP wizard issue. For improving timing to 125M,i have to configure 16bit PCIE wrapper from GTP wizard manually for FPGA prototype.However,i am very puzzle that there are too many parameters to configure for the gtp_dual of pcie tile file. I try to replace the all gtp_dual parameters of pcie tile file with the other PCIE Endpointx1(clk ration:1/2;8bit wrapper) IP without any modify. Two questions: a> Does any parameter need to be modified for working with 16bit wrapper successful by referenceing the 8bit wrapper? b>In simulation environment,the return first complete data are ALL 0 after the first Memry Read non-post request.however,all subsequences post/non-post transactions ,or remove the PCIE PHY mode ,or the second same Memry Read non-post request are ok. why cann't the first data be returned correctly?Article: 130253
Hello everyone,
After banging our heads for last few weeks (sometimes literally), I
figure I'll query the group of experts here. We have a design that is
functionally correct (ModelSim test bench) but it appears to be very iffy
when it gets on the real chip. I have a couple copies of "identical" boards
with Virtex2-1000 chips on them. I'll check again soon, but I believe they
are -6 parts. We've been synthesizing the design in Synplify Pro (v7.5
though others are available; this design has some history of working fine).
Sometimes it works on one or more boards, other times after I load it (and
verify) with iMPACT this counter acts screwy (it messes up critical timing,
and it also looks all wrong on Chipscope). Today I got brave enough to load
it into the EEPROM; it worked this afternoon but who knows tomorrow (grrr).
Looking at the Synplify timing report (with -4 speed setting in Synplify),
the timing is marginal for a specified clock of 100 MHz around this path,
but the chip is really running at 66 MHz (PCI clock). The key code is very
simple (some syntax may be a bit off since I'm doing it from memory). We
tried trimming the size of the counter from 32 bits down to 20 and it seems
to help some.
signal my_counter : std_logic_vector(COUNT_WIDTH-1 downto 0);
countdown_process: process (CLK)
begin
if rising_edge(CLK) then -- do everything synchronous
if RESET = '1' then
my_counter <= ZEROIZE_COUNT;
elsif counter_load = '1' then
my_counter <= input_bus(COUNT_WIDTH-1 downto 0);
elsif making_data = '1' then
my_counter <= my_counter - '1';
endif
endif -- CLK
end -- process
Another process block checks that this counter is nonzero and a few other
requirements to set the value of making_data true or false.
Ideas/suggestions? My main FPGA engineer has been working with the local
Xilinx FAE but no "Eureka!" moments yet. A very similar (if anything,
somewhat larger) design has never shown this trouble on the same boards. The
current design takes about 45% of the LUTs.
I notice the RTL shows this using an adder (it fans out making_data to
COUNT_WIDTH bits so that it becomes either the 0 or -1 to add). Isn't there
a simpler structure to define a count(down) counter? I sure can buy a simple
counter in 74xx series logic. I notice neither arith_std or numeric_std
define special operators (a la C's ++ and -- operators) to specify
increment/decrement, so maybe there is no simple way to create a counter
structure in fewer FPGA logic elements. Seems odd to me (non-EE).
Thanks in advance for your sagacity.
-Dr. Marty Ryba
Mad GNSS scientist
Article: 130254Hello, I'm trying to identify the critical path of a sequential circuit using the TimeQuest Timing Analyzer. However, I'm facing some dificulties because the tool doesn't provide, as the Classic Timing Analyzer used to do, any table showing the worst-case paths of the circuit. Instead, the TimeQuest generates a table with the Required Width, the Actual Width and the Slack refering to the pulse. How can I find, based on this provided information, the critical delay of the circuit? Thanks a lot. Guirico C.Article: 130255
You can tell Quartus to use the Classic Timing Analyzer by going into the Timing Analysis Settings. Guirico C. wrote: > Hello, > > I'm trying to identify the critical path of a sequential circuit using > the TimeQuest Timing Analyzer. However, I'm facing some dificulties > because the tool doesn't provide, as the Classic Timing Analyzer used > to do, any table showing the worst-case paths of the circuit. Instead, > the TimeQuest generates a table with the Required Width, the Actual > Width and the Slack refering to the pulse. > How can I find, based on this provided information, the critical delay > of the circuit? > > Thanks a lot. > Guirico C.Article: 130256
Hi, Rob. Thanks for answering. Actually, I can't use the Classic Timing Analyzer. I need to use the data obtained from TimeQuest, which is recommended by Altera for CMOS 65nm projects. Guilherme C. On 19 mar, 00:20, Rob <buz...@leavemealone.com> wrote: > You can tell Quartus to use the Classic Timing Analyzer by going into > the Timing Analysis Settings. > > Guirico C. wrote: > > Hello, > > > I'm trying to identify the critical path of a sequential circuit using > > the TimeQuest Timing Analyzer. However, I'm facing some dificulties > > because the tool doesn't provide, as the Classic Timing Analyzer used > > to do, any table showing the worst-case paths of the circuit. Instead, > > the TimeQuest generates a table with the Required Width, the Actual > > Width and the Slack refering to the pulse. > > How can I find, based on this provided information, the critical delay > > of the circuit? > > > Thanks a lot. > > Guirico C.Article: 130257
Marty Ryba wrote:
> Another process block checks that this counter is nonzero and a few other
> requirements to set the value of making_data true or false.
>
> Ideas/suggestions?
Combine the two processes into one.
-- Mike Treseler
Article: 130258
Hi,
I am trying to write values in to the slave registers through a
c code.The problem here is that i am not getting a connection between
hardware and software.Though the c code ,I am not able to write into
or read from the registers.somebody please tell me ,what may be the
reason?or somebody please show some sample code.
Article: 130259On Tue, 18 Mar 2008 21:12:57 -0700 (PDT), jithinpremvas@gmail.com wrote: >Hi, > I am trying to write values in to the slave registers through a >c code.The problem here is that i am not getting a connection between >hardware and software.Though the c code ,I am not able to write into >or read from the registers.somebody please tell me ,what may be the >reason?or somebody please show some sample code. If you show us what you are trying to do (some code), we may be able to help you. ZaraArticle: 130260
On Sun, 16 Mar 2008 09:24:10 -0700 (PDT), Antti <Antti.Lukats@googlemail.com> wrote: >On 16 Mrz., 17:18, Antti <Antti.Luk...@googlemail.com> wrote: >> ERROR:HDLParsers - Cannot reanme dependency database for library >> "work", file is "xst/work/hdpdeps.ref". Temporary database file "C:\ >> \prj\fpga\s3ask\uart_bypass\xst\work\xil_284_5" will remain. System >> error message is: No such file or directory >> >> any idea or solution? >> hopefully the solution isnt ISE 10.1 >> >> Antti > >Problem issue tracked down. > >ISE 9.2SP4 is recognized AS VIRUS, so disabling antti-virus software >will let the HDL parser to pass without errors. > >Why and how has xilinx managed to create software that triggers virus >on alert on task "HDL parse" ??? Probable, the antivirus cries out of a heuristic analysis. Try relaxing it. I recommend avira free or payed versions, they also have false triggering (I have doen two programs that trigger it!), but at least you have full control. Best regards, ZaraArticle: 130261
Hi I have been think and part time working towards a goal to make useable and useful serialized processor. The idea is that it should be 1) VERY small when implemented in any modern FPGA (less 25% of smallest device, 1 BRAM) 2) be supported by high level compiler (C ?) 3) execute code in-place from either serial flash (Winbond quad speed SPI memory delivers 320 mbit/s!) or from file on sd-card serial implementation would be smaller and run at higher speeds, so 128 clock per machine cycle would already mean 2 MIPS, what would be acceptable for many applications. Parallax basic stamps I executes 2KIPS only, so ultra lite serial processor in FPGA with 2 MIPS would be eh, for me its some to dream off :) I have poked around this idea for some years, but never got the "final kick" to really go and do-complete the design and development of this processor. So I decided to offer some bounty for others to maybe motivate to work for this goal and dream, current list of items available for the developers from my own funding is listed here (I hope to add items and maybe some $ by the time) http://code.google.com/p/serial-processor/w/list there is also very preliminary spec-goal document as well Antti LukatsArticle: 130262
Marty Ryba wrote: > countdown_process: process (CLK) > begin > if rising_edge(CLK) then -- do everything synchronous > if RESET = '1' then > my_counter <= ZEROIZE_COUNT; > elsif counter_load = '1' then > my_counter <= input_bus(COUNT_WIDTH-1 downto 0); > elsif making_data = '1' then > my_counter <= my_counter - '1'; > endif > endif -- CLK > end -- process > > Another process block checks that this counter is nonzero and a few other > requirements to set the value of making_data true or false. I've been banging my head as well trying to improve poor legacy code to pass timing at 250Mhz, for the last month. Based on this experience, I'd suggest registering *everything*... well, as much as possible. Make sure your making_data is a flop, 'cos if it is combinatorial and based on my_counter, that's a recipe for failure. HTH, -P@Article: 130263
On 18 mar, 19:49, picnan...@yahoo.fr wrote: > On 18 mar, 19:13, Mike Treseler <mike_trese...@comcast.net> wrote: > > > picnan...@yahoo.fr wrote: > > > I can't see all vhdl variable. > > > try > > > --disp-tree=proc > > Thank for you help but where does I set this option? > inside ghdl -a line or ghdl -c line i find where i can place it ghdl -c --ieee=synopsys -fexplicit --std=93 -r bench --disp-tree=proc --stop-time=7000ns --wave=bench.ghw this option don't allow see variable.Article: 130264
I notice neither arith_std or numeric_std > define special operators (a la C's ++ and -- operators) to specify > increment/decrement, so maybe there is no simple way to create a counter > structure in fewer FPGA logic elements. Seems odd to me (non-EE). > Thats because ++ -- are nothing special, it still requires an adder with the the 1st input as the registered output of the adder, and the 2nd tied to +-1. An FPGA is just an array of LUTs, flip-flops and RAMs, not alot more (some FPGAs may have dedicated multipliers too). As for the "making_data" becoming the 2nd adder input, Im surprised. It might be better if you can try and force it to synthesize "making_data" as the adder's register enable rather than the 2nd adder input, and then you can keep the 2nd adder input as a constant -1. As to how to do this, Im not sure. How about changing "my_counter" into an unsigned instead (or signed, makes no difference) using the numeric_std package (implementation is IEEE defined) instead of the std_logic_arith package (implementation is Vendor defined, and non- standard).Article: 130265
thanks for all the answers! just tried it and yes it works in ise too! Urban StadlerArticle: 130266
Marty Ryba wrote: > Hello everyone, > > After banging our heads for last few weeks (sometimes literally), I > figure I'll query the group of experts here. We have a design that is > functionally correct (ModelSim test bench) but it appears to be very iffy > when it gets on the real chip. I have a couple copies of "identical" boards > with Virtex2-1000 chips on them. I'll check again soon, but I believe they > are -6 parts. We've been synthesizing the design in Synplify Pro (v7.5 > though others are available; this design has some history of working fine). > Sometimes it works on one or more boards, other times after I load it (and > verify) with iMPACT this counter acts screwy (it messes up critical timing, > and it also looks all wrong on Chipscope). Today I got brave enough to load > it into the EEPROM; it worked this afternoon but who knows tomorrow (grrr). > Looking at the Synplify timing report (with -4 speed setting in Synplify), > the timing is marginal for a specified clock of 100 MHz around this path, > but the chip is really running at 66 MHz (PCI clock). The key code is very > simple (some syntax may be a bit off since I'm doing it from memory). We > tried trimming the size of the counter from 32 bits down to 20 and it seems > to help some. When you have symptoms like this, that suggest the real limit is lower than the tools report, have you tried variable clocking speeds, to check if at 10MHz or 1MHz, it DOES work properly ? > > I notice the RTL shows this using an adder (it fans out making_data to > COUNT_WIDTH bits so that it becomes either the 0 or -1 to add). Isn't there > a simpler structure to define a count(down) counter? I sure can buy a simple > counter in 74xx series logic. I notice neither arith_std or numeric_std > define special operators (a la C's ++ and -- operators) to specify > increment/decrement, so maybe there is no simple way to create a counter > structure in fewer FPGA logic elements. Seems odd to me (non-EE). In a counter, you usually need to 'see' the state of the lower bits to decide when to toggle the upper bit - and in a FPGA the carry chain is often faster than other paths, so that makes adders a natural counter solution. Certainly easy to write. For long counters, the carry pathway can limit the speed, then you can split it and make it more complex, but faster. Look at 74161 for a faster carry scheme. -jgArticle: 130267
markmcmahon@hotmail.com writes: >> Where are you going to DMA to? Won't the processor need to execute an >> instruction to access every sample of data then as well? And wait the >> memory latency (if any). >> >> Personally, I would use a FIFO on the FSL. It seems a lot simpler >> than DMA! >> <snip q's on adding FIFOs, I hope Göran answered those :-)> > > As to the overhead, I'm assuming I would get one interrupt per 200 > samples from the FIFO instead of servicing 200 interrupts from the > FSL. If your processing is sequential (sorry, I've assumed up 'til now that it was), you set up your FSL hardware to interrupt you when you have enough data, so 200 samples in your case. At that point, you can run your processing routine. No *extra* data transfers are required, you just read a sample from the FSL and process it. If you need random access to your 200 samples, then use one port of a dual port BRAM to store the samples from your peripheral directly. You can then interrupt the processor when it's done and have fast random access to the BRAM via the local memory bus (LMB). No FIFO, no FSL, just memory. It is DMA of a sort, but you've got a private dedicated port for your data gathering peripheral, so a lot less hassle than doing bus-mastering on a shared bus. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 130268
> I have been think and part time working towards a goal to make useable
> and useful serialized processor.
The idea is not new, according to
Denyer, Renshaw "VLSI Signal Processing A Bit serial Approach"
Addison-Wesley 1985
there were machines back in the 50ies, 60ies ( Pilot ACE 1953 ).
Description of a typical application would be
"Speech Codec architecture for Pan-European Digital Mobile Radio
using bit-serial Signal processing" ( Nokia & Tampere University )
in: Brodersen "VLSI Signal Processing III" IEEE Press 1988
Thats a DSP for GSM, fixed application.
But serial 8 bit microprocessors like the MC6803 or ST62xx were
a slow nuisance.
MfG JRD
Article: 130269Antti wrote: > Hi > > I have been think and part time working towards a goal to make useable > and useful serialized processor. The idea is that it should be > > 1) VERY small when implemented in any modern FPGA (less 25% of > smallest device, 1 BRAM) > 2) be supported by high level compiler (C ?) That means an existing core ? Did someone mention an 8080 earlier - how small is that ? To work best with serial memory, a smart set of skip opcodes is needed. eg Conditional skip of 1,2,3,4 opcodes. Jumps are very slow, tho to accept existing cores, I suppose some (small enough?) extra logic could be added that 'sniffed' the jump opcodes, and diverted the very small forward ones to a Skip-Instead block ? > 3) execute code in-place from either serial flash (Winbond quad speed > SPI memory delivers 320 mbit/s!) or from file on sd-card What about adding this for DATA memory option ? SPI SRAM. http://www.amis.com/products/ulp_memory/serial_srams/index.html > > serial implementation would be smaller and run at higher speeds, so > 128 clock per machine cycle would already mean 2 MIPS, what would be > acceptable for many applications. I'd target the Winbond Quad parts as a primary target, and look at 1, 2, 4 bit serial choices. (1 bit may not be the smallest?) 4 bit (nibble serial) would look to have merit, as it matches the memory, and you also can do 8/16/(24?)/32 cores, with simply wider busses. IIRC, natsemi used 10 clocks on their COP's which gave 8 clocks to transport data, and 2 clocks for opcode-action. 2 Winbond devices would morph this to 4 DT clocks + 2 opcode, for a 6 clock Core. -jgArticle: 130270
"Marty Ryba" <martin.ryba.nospam@verizon.net> writes: > Hello everyone, > > After banging our heads for last few weeks (sometimes literally), I > figure I'll query the group of experts here. We have a design that is > functionally correct (ModelSim test bench) but it appears to be very iffy > when it gets on the real chip. I have a couple copies of "identical" boards > with Virtex2-1000 chips on them. I'll check again soon, but I believe they > are -6 parts. We've been synthesizing the design in Synplify Pro (v7.5 > though others are available; this design has some history of working fine). > Sometimes it works on one or more boards, other times after I load it (and > verify) with iMPACT this counter acts screwy (it messes up critical timing, > and it also looks all wrong on Chipscope). Today I got brave enough to load > it into the EEPROM; it worked this afternoon but who knows tomorrow (grrr). > Looking at the Synplify timing report (with -4 speed setting in Synplify), > the timing is marginal for a specified clock of 100 MHz around this path, > but the chip is really running at 66 MHz (PCI clock). What does the Xilinx timing report say? Have you constrained the clock correctly (or indeed at all :-)? Synplify's report is an educated guess on the part of the tools. Xilinx's represents what they think the absolute worst-case is, so if it thinks you meet your timing constraints, then any chip you get will run that design. Of course, that depends on your constraints being right :-) You say this design has a history of working fine - what's changed since then? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 130271
On 19 Mar, 04:13, "Marty Ryba" <martin.ryba.nos...@verizon.net> wrote: > Hello everyone, > > =A0 =A0 After banging our heads for last few weeks (sometimes literally), = I > figure I'll query the group of experts here. We have a design that is > functionally correct (ModelSim test bench) but it appears to be very iffy > when it gets on the real chip. I have a couple copies of "identical" board= s > with Virtex2-1000 chips on them. I'll check again soon, but I believe they= > are -6 parts. We've been synthesizing the design in Synplify Pro (v7.5 > though others are available; this design has some history of working fine)= . > Sometimes it works on one or more boards, other times after I load it (and= > verify) with iMPACT this counter acts screwy (it messes up critical timing= , > and it also looks all wrong on Chipscope). Today I got brave enough to loa= d > it into the EEPROM; it worked this afternoon but who knows tomorrow (grrr)= . > Looking at the Synplify timing report (with -4 speed setting in Synplify),= > the timing is marginal for a specified clock of 100 MHz around this path, > but the chip is really running at 66 MHz (PCI clock). The key code is very= > simple (some syntax may be a bit off since I'm doing it from memory). We > tried trimming the size of the counter from 32 bits down to 20 and it seem= s > to help some. > > signal my_counter : std_logic_vector(COUNT_WIDTH-1 downto 0); > > countdown_process: process (CLK) > begin > =A0 if rising_edge(CLK) then =A0 =A0 =A0 =A0-- do everything synchronous > =A0 =A0 if RESET =3D '1' then > =A0 =A0 =A0 =A0my_counter <=3D ZEROIZE_COUNT; > =A0 =A0 elsif counter_load =3D '1' then > =A0 =A0 =A0 my_counter <=3D input_bus(COUNT_WIDTH-1 downto 0); > =A0 =A0 elsif making_data =3D '1' then > =A0 =A0 =A0 my_counter <=3D my_counter - '1'; > =A0 =A0 endif > =A0 endif =A0-- CLK > end -- process > > Another process block checks that this counter is nonzero and a few other > requirements to set the value of making_data true or false. > > Ideas/suggestions? My main FPGA engineer has been working with the local > Xilinx FAE but no "Eureka!" moments yet. A very similar (if anything, > somewhat larger) design has never shown this trouble on the same boards. T= he > current design takes about 45% of the LUTs. > > I notice the RTL shows this using an adder (it fans out making_data to > COUNT_WIDTH bits so that it becomes either the 0 or -1 to add). Isn't ther= e > a simpler structure to define a count(down) counter? I sure can buy a simp= le > counter in 74xx series logic. I notice neither arith_std or numeric_std > define special operators (a la C's ++ and -- operators) to specify > increment/decrement, so maybe there is no simple way to create a counter > structure in fewer FPGA logic elements. Seems odd to me (non-EE). > > Thanks in advance for your sagacity. > > -Dr. Marty Ryba > Mad GNSS scientist Just some ideas: Are all control signals synchronous to "CLK" ? Is the clock "clean"? What about supply voltage (DC-level, ripple, decoupling etc)? Could it be a board layout problem (insufficient ground plane, crosstalk)? If the long carry chain is the problem, you may divide the counter into 2 smaller counters with a pipelined carry chain. /PeterArticle: 130272
Will the 10th edition of ISE, to be relealed next week, finally support multithreading/SMP machines to reduce synthesis + P&R time? Will we finally get support for synthesis of System Verilog constructs? What other major features to you still miss? - Discuss!Article: 130273
On 19 Mar, 11:20, ratztafaz <heinerl...@googlemail.com> wrote: > Will the 10th edition of ISE, to be relealed next week, finally > support multithreading/SMP machines to reduce synthesis + P&R time? > > Will we finally get support for synthesis of System Verilog > constructs? > > What other major features to you still miss? - Discuss! Full Verilog 2001 support! JonArticle: 130274
"Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:u4pb3m2ti.fsf@trw.com... > "Marty Ryba" <martin.ryba.nospam@verizon.net> writes: > > > What does the Xilinx timing report say? Have you constrained the > clock correctly (or indeed at all :-)? > ^^^ What he said. Syms.
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