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
Antti, Do not want to raise any hackles, but you are correct about the demandperipherials knock off, perceptive. I talked with Bob Smith about a couple of things and he basically said go away, I understand and with no further ado I did. Here is a picture of my finished product, http://www.mediafire.com/?sharekey=923066edf8d516eeed24a2875c7fa58ee04e75f6e8ebb871 I agree about the so simple part, However there is something interesting in this problem I have described, I just have not found it. SPI works fine and is not part of the usb programming, indirect JTAG only. I am not sure how the FT245RL can strobe its own read line and produce a CCLK in order to load the data into FPGA, if you are willing to elaborate im willing to read. I went for a swim to clear my head it works every time. Will give your suggestions a closer look. I have so much completed on this board from absolutely nothing to 95% working it is a great project and will be taking this open source. I wonder why my work is not necessary? Antti, thanks for chatting not looking to raise any hackles, but am glad for the help. Cy DrollingerArticle: 142951
Rob Gaddi wrote:
> I was just starting to try to do some playing with TCL, and ran into an
> interesting problem. If you're running bash through Cygwin:
cygwin is a time bandit.
try cmd.exe tcl or wish
or modelsim transcript
or linux bash.
Good luck.
-- Mike Treseler
Article: 142952On Sep 10, 1:18=A0am, nobody <cydrollin...@gmail.com> wrote: > Antti, > > Do not want to raise any hackles, but you are correct about the > demandperipherials knock off, perceptive. I talked with Bob Smith > about a couple of things and he basically said go away, I understand > and with no further ado I did. Here is a picture of my finished > product,http://www.mediafire.com/?sharekey=3D923066edf8d516eeed24a2875c7f= a58ee0... > > I agree about the so simple part, However there is something > interesting in this problem I have described, I just have not found > it. > > SPI works fine and is not part of the usb programming, indirect JTAG > only. > > I am not sure how the FT245RL can strobe its own read line and produce > a CCLK in order to load the data into FPGA, if you are willing to > elaborate im willing to read. > > I went for a swim to clear my head it works every time. > > Will give your suggestions a closer look. > > I have so much completed on this board from absolutely nothing to 95% > working it is a great project and will be taking this open source. I > wonder why my work is not necessary? > > Antti, thanks for chatting not looking to raise any hackles, but am > glad for the help. > > Cy Drollinger Cy pretty much NO ONE in the open-source community is inteterested in 4 layer PCB with S3E ALL S3E board level products are DISCONTINUED by Xilinx if Xilinx has discontinued, why do you want to promote something Xilinx itself wants to forget? your board is TOO expensive option: step 1: take S3AN add LDO, and RJ45 jack and 100 mil header PCB should be REAL simple and 2 layers only step 2: ask U2TOOL OEM pricing (coming soon www.u2tool.com ) step 3: bundle items [1] and [2] you can do step 2 before step 1 :) AnttiArticle: 142953
Not really helpful with the original question, unfortunately. Xilinx MIG (memory interface generator) hides I/Os deep in the design hierarchy. Too bad I don't have access to the code to see what the proper syntax is. "System level simulation won't be possible as the IOs are not accessible" Sorry to correct you here, but attaching SDRAM simulation models to dedicated internal controller blocks is even easier than to the top level. Finally, making the design internal makes it much more portable, as you can simply pass the controller interface with instantiated I/O buffers and I/O to one of your engineers, and they never have to do anything but work with the interface. BTW, Xilinx realized recently that this is much more advantageous from hardware standpoint than the ancient top level driven designs: the latest ISE 10 allows multiple .ucf files for this reason.Article: 142954
Not really helpful with the original question, unfortunately. Xilinx MIG (memory interface generator) hides I/Os deep in the design hierarchy. Too bad I don't have access to the code to see what the proper syntax is. "System level simulation won't be possible as the IOs are not accessible" Sorry to correct you here, but attaching SDRAM simulation models to dedicated internal controller blocks is even easier than to the top level. Finally, making the design internal makes it much more portable, as you can simply pass the controller interface with instantiated I/O buffers and I/O to one of your engineers, and they never have to do anything but work with the interface. BTW, Xilinx realized recently that this is much more advantageous from hardware standpoint than the ancient top level driven designs: the latest ISE 10 allows multiple .ucf files for this reason.Article: 142955
On Sep 9, 10:35=A0pm, Telenochek <elet.mir...@gmail.com> wrote: > Not really helpful with the original question, unfortunately. > > Xilinx MIG (memory interface generator) hides I/Os deep in the design > hierarchy. > Too bad I don't have access to the code to see what the proper syntax > is. > > "System level simulation won't be possible as the IOs are not > accessible" > Sorry to correct you here, but attaching SDRAM simulation models to > dedicated internal controller blocks is even easier than to the top > level. > > Finally, making the design internal makes it much more portable, as > you can simply pass the controller interface with instantiated I/O > buffers and I/O to one of your engineers, and they never have to do > anything but work with the interface. > > BTW, Xilinx realized recently that this is much more advantageous from > hardware standpoint than the ancient top level driven designs: the > latest ISE 10 allows multiple .ucf files for this reason. Actually, I think that the suggestion to bring the IO ports to the top level is helpful to your orginal question as it appears that the net name on the IO port of the IOBUF is different than you expected it to be and this would solve the problem. One addition suggestion, since you don't want to propogate the signal then try adding the LOC to the instance name which likely has not changed. INST "eight_chan_gen/u1/external_sdram/U1/IOBUF_inst0" LOC =3D "A4"; With respect to your comments on the MIG output, the physical level interface is presented on the core interface with the intent that nets are connected to the top level ports in the design. This is shown in all of the design examples. I have no idea how "attaching SDRAM simulation models to the dedicated internal memory blocks" is easier. Please elaborate on why this is easier to use and maintain between simulation and synthesis. Ed McGettigan -- Xilinx Inc.Article: 142956
On 9 Sep, 17:48, DJ Delorie <d...@delorie.com> wrote: > Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> writes: > > We ask for registration, > > Er, your privacy policy says you can spam us and change your policy at > any time. =A0Can we get something a little more user-friendly than that? Ah, now I remember why I have several trashable gmail and yahoo accounts. Is my name Colin?... sometimes it's hard to remember.Article: 142957
On Wed, 9 Sep 2009 23:09:58 -0700 (PDT), Ed McGettigan <ed.mcgettigan@xilinx.com> wrote: >On Sep 9, 10:35 pm, Telenochek <elet.mir...@gmail.com> wrote: >> Not really helpful with the original question, unfortunately. >> >> Xilinx MIG (memory interface generator) hides I/Os deep in the design >> hierarchy. >> Too bad I don't have access to the code to see what the proper syntax >> is. >> >> "System level simulation won't be possible as the IOs are not >> accessible" >> Sorry to correct you here, but attaching SDRAM simulation models to >> dedicated internal controller blocks is even easier than to the top >> level. >I have no idea how "attaching SDRAM simulation models to the dedicated >internal memory blocks" is easier. Please elaborate on why this is >easier to use and maintain between simulation and synthesis. I haven't done this; I confess I hadn't thought of it (being blinded by starting from the Xilinx examples) but I can see how it would work... You create a DDR block, e.g. a wrapper covering (MIG, all external ports, the logic you must add to make MIG usable, AND the sim models) and then test the hell out of it (a testbench instantiates the whole block). For synthesis, the IOBs are inserted as instantiated, and the sim models are not (they are guarded by "translate" pragmas). This whole block can be dropped into a user design without having to add superfluous ports on the instantiating block; the top level block; every hierarchical level in between; AND the testbench. That eliminates a huge maintenance task, e.g. when you later change the memory size, you have to add address and BA bits to every level and the testbench too. Oh and you used this subsystem in a couple of dozen designs, so you have to update over a hundred files to let someone plug a bigger SODIMM into the ML505. Better to keep the I/Os and the sim models in the instantiated block; and simply drop that, whole, into a user design. Just solve the tool flow issues first... For an even better example of the maintenance nightmare approach, take a look at how I/O signals are routed in the insane PCIe endpoint example design, as created by Coregen. - BrianArticle: 142958
Hi *, I'm trying to use functions from math_real to calculate some constants in a VHDL package. In Precision and XST, this works fine. When I try to synthesize it with the Synplify-version shipped with the Lattice ispLever tools, it complains that the functions I want to use are not declared (ironically, it does NOT complain that math_real is not available when the corresponding "use"-statement is compiled). I can't find any definitive statement on this in the documentation... math_real is not listed in the table of "Predefined VHDL Libraries and Packages", but they ship an encrypted version of the source in $LATTICE_FOLDER/synpbase/lib/vhd. Adding this file to the synthesis project only results in syntax errors, so this is useless. Can't find any info on this on the Lattice website, either. Can't register for Synplicity-support since for registration they want a site ID, which I don't have, since the version I use was not bought from Synopsys but shipped with the Lattice tools... So, I suppose math_real is simply not supported at all by Synplify? Or is this some restriction in the Lattice-release? cu, Sean -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).Article: 142959
Sean Durkin wrote: > Hi *, > > I'm trying to use functions from math_real to calculate some constants > in a VHDL package. In Precision and XST, this works fine. > > When I try to synthesize it with the Synplify-version shipped with the > Lattice ispLever tools, it complains that the functions I want to use > are not declared (ironically, it does NOT complain that math_real is not > available when the corresponding "use"-statement is compiled). > > I can't find any definitive statement on this in the documentation... > math_real is not listed in the table of "Predefined VHDL Libraries and > Packages", but they ship an encrypted version of the source in > $LATTICE_FOLDER/synpbase/lib/vhd. Adding this file to the synthesis > project only results in syntax errors, so this is useless. > > Can't find any info on this on the Lattice website, either. Can't > register for Synplicity-support since for registration they want a site > ID, which I don't have, since the version I use was not bought from > Synopsys but shipped with the Lattice tools... > For your information, Synopsys Solvnet does state that synplify supports math_real. The article refers to "synplify, synplify_pro" and is dated 25/01/2007. But maybe that doesn't apply to OEM versions of synplify - it doesn't say. regards Alan > So, I suppose math_real is simply not supported at all by Synplify? Or > is this some restriction in the Lattice-release? > > cu, > Sean > -- Alan Fitch Senior Consultant Doulos – Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.Article: 142960
Hi Alan, Alan Fitch wrote: > For your information, Synopsys Solvnet does state that synplify supports > math_real. The article refers to "synplify, synplify_pro" and is dated > 25/01/2007. > > But maybe that doesn't apply to OEM versions of synplify - it doesn't say. thanks for the info. I'll have to contact Lattice and ask them, I suppose... And in the meantime work around the problem... cu, Sean -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).Article: 142961
Hi try to send the value in HEX, I had the same problem trying sending ASCII but it not work constant dato1 : std_logic_vector(7 downto 0) := X"44";--VHDL code, transmit a D out the UART RS232 JPArticle: 142962
On Sep 10, 4:02=A0am, "jaimico" <p_jai...@hotmail.com> wrote: > Hi > try to send the value in HEX, I had the same problem trying sending ASCII > but it not work > > constant dato1 : std_logic_vector(7 downto 0) :=3D X"44";--VHDL code, > transmit a D out the UART RS232 > > JP Do you have a `timescale directive appropriately placed? Are you sure you're in ns? You probably want something like `timescale 1 ns / 10 ps John ProvidenzaArticle: 142963
Sean Durkin schrieb: > Hi *, > > I'm trying to use functions from math_real to calculate some constants > in a VHDL package. In Precision and XST, this works fine. > > When I try to synthesize it with the Synplify-version shipped with the > Lattice ispLever tools, it complains that the functions I want to use > are not declared (ironically, it does NOT complain that math_real is not > available when the corresponding "use"-statement is compiled). > > I can't find any definitive statement on this in the documentation... > math_real is not listed in the table of "Predefined VHDL Libraries and > Packages", but they ship an encrypted version of the source in > $LATTICE_FOLDER/synpbase/lib/vhd. Adding this file to the synthesis > project only results in syntax errors, so this is useless. > > Can't find any info on this on the Lattice website, either. Can't > register for Synplicity-support since for registration they want a site > ID, which I don't have, since the version I use was not bought from > Synopsys but shipped with the Lattice tools... > > So, I suppose math_real is simply not supported at all by Synplify? Or > is this some restriction in the Lattice-release? In case anyone's interested: It works fine if you start Synplify stand-alone, not through the ispLever project navigator. I guess ispLever adjusts the path where Synplify is looking for its pre-compiled libraries to somewhere where libs with Lattice-cores are available but not math_real... cu, Sean -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).Article: 142964
Got an email from Altera. It pointed me to a movie clip. The movie clip shows a sales manager ? and application engineer explaining the latest and greatest high speed development board (think it was). No problem so far, except that both these persons speak what can perhaps best be described as 'Indian or Pakistani English'. Very very hard to make it out, had to stop that video and let sink in what they were on about. Is that the new US standard pronunciation? Or is the market far east anyways an there they all speak like that? How about giving at least your sales rep a tutorial on how to pronounce US English (or UK English)? Is this the new trend?Article: 142965
On Sep 10, 6:27=A0pm, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote: > Got an email from Altera. > It pointed me to a movie clip. > The movie clip shows a sales manager ? and application engineer explainin= g > the latest and greatest high speed development board (think it was). > No problem so far, except that both these persons speak what can perhaps > best be described as 'Indian or Pakistani English'. > Very very hard to make it out, had to stop that video and let sink in wha= t they were on about. > > Is that the new US standard pronunciation? > Or is the market far east anyways an there they all speak like that? > > How about giving at least your sales rep a tutorial on how to > pronounce US English (or UK English)? > Is this the new trend? yes, it isArticle: 142966
This is just a ploy to get us to go and watch the video that we didn't bother watching first time round. Isn't it? Nial.Article: 142967
Completion, The FPGA never releases the Global Three State(GTS) after done goes high, described in DS312 pg. 107, because the fpga_cclk shuts down one clock cycle to early. After the revision of taking out the need to program while FPGA_initb is high gives the extra fpga_cclk needed to release GTS signal and drives the High Z FPGA_d bus. One stinking clock cycle who knew? Sincerely, Cy DrollingerArticle: 142968
On Sep 10, 4:36=A0pm, nobody <cydrollin...@gmail.com> wrote: > Completion, > > The FPGA never releases =A0the Global Three State(GTS) after done goes > high, described in DS312 pg. 107, because the fpga_cclk shuts down one > clock cycle to early. After the revision of taking out the need to > program while FPGA_initb is high gives the extra fpga_cclk needed to > release GTS signal and drives the High Z FPGA_d bus. One stinking > clock cycle who knew? > > Sincerely, > > Cy Drollinger You can change the order of the startup events in the bitgen options. I've have similar problems when using a micro to load the FPGA and stopping as soon as DONE is high. The default startup sequence sets DONE high before releasing GSR. For a design with only one FPGA this is not necessary. The intent is to synchronize startup of multiple devices in a chain. Regards, GaborArticle: 142969
"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message news:h8b5tj$jc2$1@news.albasani.net... > Got an email from Altera. > It pointed me to a movie clip. > The movie clip shows a sales manager ? and application engineer > explaining > the latest and greatest high speed development board (think it was). > No problem so far, except that both these persons speak what can > perhaps > best be described as 'Indian or Pakistani English'. > Very very hard to make it out, had to stop that video and let sink in > what they were on about. > > Is that the new US standard pronunciation? > Or is the market far east anyways an there they all speak like that? > > How about giving at least your sales rep a tutorial on how to > pronounce US English (or UK English)? > Is this the new trend? > Hope not. I can't understand them either. Just wish they fix their password reset feature on their web site. CheersArticle: 142970
On Sep 10, 11:36=A0pm, nobody <cydrollin...@gmail.com> wrote: > Completion, > > The FPGA never releases =A0the Global Three State(GTS) after done goes > high, described in DS312 pg. 107, because the fpga_cclk shuts down one > clock cycle to early. After the revision of taking out the need to > program while FPGA_initb is high gives the extra fpga_cclk needed to > release GTS signal and drives the High Z FPGA_d bus. One stinking > clock cycle who knew? > > Sincerely, > > Cy Drollinger Cy this was actually OBVIOUS, I assumed you KNOW FPGA is configured AND working (this is not same as done=3D1) it is always wise to send extra clocks after done=3D1... this is for me common knowledge i should have suggested this earlier, but i assumed you DID know that FPGA was actually driving the pins btw bus conflict and non-driving bus can be seen as different with DSO or even multimeter AnttiArticle: 142971
Dear list, I have gotten my hands on a Rakon SPXO003204 50 Mhz crystal oscillator, DIP-8 package: http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=226-2250&x=0&y=0 (datasheet http://docs-europe.electrocomponents.com/webdocs/013b/0900766b8013b634.pdf) But something about its behaviours puzzles me: To start with, the datasheet says: "Supply Voltage: 5V ±0.25V". I have hooked this crystal to a lab power supply, where I can change the supply voltage, and I start slowly increasing the voltage. From 0, up to until about 2.6V power supply, the oscillator behaves as I expect - that is, the output is from about 10% to about 90% of supply voltage, as per datasheet: http://img222.imageshack.us/img222/1258/xooscmeas01.jpg (excuse the poor quality, I cannot focus the camera any better. The line from channel 2 is used to indicate the zero. This scope cannot resolve 50 Mhz, so I'm just using the shaded area as indication of oscillations) However, as soon as I cross 2.6V power supply, the working regime sort of flips - and apparently there are some oscillations, but from roughly 70% to 90% of power supply - for instance, here is how it looks for the 5V supply (as per datasheet) http://img222.imageshack.us/img222/5435/xooscmeas02.jpg My questions are: * Is this the expected behavior of this crystal oscillator - or is this maybe a damaged part? * Since this was just the oscillator connected directly to power supply (no capacitors or anything as per "Test Circuit" in the datasheet), should I maybe expect that external components would make a difference (in the sense of allowing output of about 10% to about 90% of supply voltage, even for 5V supply?) * If this is the expected behavior for this part - can I take that most crystal oscillators on the market will show similar behaviour? Thanks for any comments, Cheers! --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 142972
On 30 Aug, 01:41, Weng Tianxiang <wtx...@gmail.com> wrote: > I have a project continuously running more than 20 days to get an > error. In my project I have many assert statements to make sure the > design is going well. If there is an error, the design stops. > > But I couldn't open the waveform window under ModelSim when starting > the simulation, the reason is very simple: any size of hard disk would > be filled up within one day simulation. I've been in almost the same situation and I have also managed to crash our fileserver by creating a logfile that was too large... :) My solution was to use checkpoints in modelsim. 1. Compile all source code files with +acc so that it is possible to add signals to the wave window. 2. Run simulation for 1 hour or until an error occurs. 3. If no error occured, save a checkpoint with a unique serial number, go back to step 2 4. At this point you can load up the latest checkpoint, add all relevant signals to your wave window (or signal log if you like the log-command) and rerun the simulation The advantage of this approach is that you don't have to spend any computation time to log signal changes while retaining the ability to have full visibility when you are actually close to an error. Look for the checkpoint command in the Modelsim documentation for more info. /AndreasArticle: 142973
"sdaau" <sd@imi.aau.dk> wrote in message news:_eKdnbazo6OnijfXnZ2dnUVZ_rCdnZ2d@giganews.com... > Dear list, > > I have gotten my hands on a Rakon SPXO003204 50 Mhz crystal oscillator, > DIP-8 package: > > http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=226-2250&x=0&y=0 > (datasheet > http://docs-europe.electrocomponents.com/webdocs/013b/0900766b8013b634.pdf) > > But something about its behaviours puzzles me: To start with, the > datasheet says: "Supply Voltage: 5V ±0.25V". > > I have hooked this crystal to a lab power supply, where I can change the > supply voltage, and I start slowly increasing the voltage. From 0, up to > until about 2.6V power supply, the oscillator behaves as I expect - that > is, the output is from about 10% to about 90% of supply voltage, as per > datasheet: > > http://img222.imageshack.us/img222/1258/xooscmeas01.jpg > > (excuse the poor quality, I cannot focus the camera any better. The line > from channel 2 is used to indicate the zero. This scope cannot resolve 50 > Mhz, so I'm just using the shaded area as indication of oscillations) > > However, as soon as I cross 2.6V power supply, the working regime sort of > flips - and apparently there are some oscillations, but from roughly 70% > to > 90% of power supply - for instance, here is how it looks for the 5V supply > (as per datasheet) > > http://img222.imageshack.us/img222/5435/xooscmeas02.jpg > > My questions are: > * Is this the expected behavior of this crystal oscillator - or is this > maybe a damaged part? > * Since this was just the oscillator connected directly to power supply > (no capacitors or anything as per "Test Circuit" in the datasheet), should > I maybe expect that external components would make a difference (in the > sense of allowing output of about 10% to about 90% of supply voltage, even > for 5V supply?) > * If this is the expected behavior for this part - can I take that most > crystal oscillators on the market will show similar behaviour? > > Thanks for any comments, > Cheers! > > ...datasheet says: "Supply Voltage: 5V ±0.25V". All other bets are off.Article: 142974
Phil Jessop wrote: > "sdaau" <sd@imi.aau.dk> wrote in message > news:_eKdnbazo6OnijfXnZ2dnUVZ_rCdnZ2d@giganews.com... >> Dear list, >> >> I have gotten my hands on a Rakon SPXO003204 50 Mhz crystal >> oscillator, DIP-8 package: >> >> http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=226-2250&x=0&y=0 >> (datasheet >> http://docs-europe.electrocomponents.com/webdocs/013b/0900766b8013b634.pdf) >> >> But something about its behaviours puzzles me: To start with, the >> datasheet says: "Supply Voltage: 5V ±0.25V". >> >> I have hooked this crystal to a lab power supply, where I can change >> the supply voltage, and I start slowly increasing the voltage. From >> 0, up to until about 2.6V power supply, the oscillator behaves as I >> expect - that is, the output is from about 10% to about 90% of >> supply voltage, as per datasheet: >> >> http://img222.imageshack.us/img222/1258/xooscmeas01.jpg >> >> (excuse the poor quality, I cannot focus the camera any better. The >> line from channel 2 is used to indicate the zero. This scope cannot >> resolve 50 Mhz, so I'm just using the shaded area as indication of >> oscillations) However, as soon as I cross 2.6V power supply, the working >> regime >> sort of flips - and apparently there are some oscillations, but from >> roughly 70% to >> 90% of power supply - for instance, here is how it looks for the 5V >> supply (as per datasheet) >> >> http://img222.imageshack.us/img222/5435/xooscmeas02.jpg >> >> My questions are: >> * Is this the expected behavior of this crystal oscillator - or is >> this maybe a damaged part? >> * Since this was just the oscillator connected directly to power >> supply (no capacitors or anything as per "Test Circuit" in the >> datasheet), should I maybe expect that external components would >> make a difference (in the sense of allowing output of about 10% to >> about 90% of supply voltage, even for 5V supply?) >> * If this is the expected behavior for this part - can I take that >> most crystal oscillators on the market will show similar behaviour? >> >> Thanks for any comments, >> Cheers! >> >> > > ...datasheet says: "Supply Voltage: 5V ±0.25V". > > All other bets are off. My thoughts, and as the OP has suggested all's well at 90% of 5V, that the device is behaving as expected. I would expect a working range to be a little wider than specified range as indeed the OP experiences.
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