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
I just used the ISE integrated tool called 'Timing Analyzer'. So whether could I draw the conclusion that : "Async FIFO can handle two unrelated async clocks." ?Article: 141601
Hi, I have a problem with dual-port ram inference. I have a module called "dual_port_ram.vhd" that I use to infer a dual port ram. This file is based on Xilinx template and it works well almost everytime. My problem is the following, I have a module called "widget.vhd" that instantiates a 1024x20 bit dual-port ram. When I synthesize widget.vhd, I see that ISE correctly inferred the dual-port ram with 2 block rams. I have another VHDL module called "gadgets.vhd" that instantiates 4 "widget.vhd" components. We should expect ISE to synthesize "gagdets.vhd" with 8 block rams. However, when I synthesize "gadgets.vhd", ISE infers the 4 1024x20 bit dual-port ram in distributed logic instead of using 8 block rams. I have enough block rams in my device for the instantiation so it's not some kind of fallback plan by ISE synthesis. What's even weirder is that when I add the "keep_hierarchy" attribute in "widget.vhd", ISE will synthesize "gagdets.vhd" with 8 block rams instead of synthesizing it with 4 1024x20bit distributed logic ram. Does anyone here have some kind of explanation? I use ISE 11.1 with resource sharing disabled. Best regards BenjaminArticle: 141602
Benjamin Couillard wrote:
> However, when I synthesize "gadgets.vhd", ISE infers the 4 1024x20 bit
> dual-port ram in distributed logic instead of using 8 block rams. I
> have enough block rams in my device for the instantiation so it's not
> some kind of fallback plan by ISE synthesis.
Maybe there are not enough routes to
wire up the 8 block rams.
To find out, do an RTL synthesis and look at the RTL viewer.
That should ignore routing concerns.
> What's even weirder is
> that when I add the "keep_hierarchy" attribute in "widget.vhd", ISE
> will synthesize "gagdets.vhd" with 8 block rams instead of
> synthesizing it with 4 1024x20bit distributed logic ram.
That might be the right answer.
You have given synthesis the hint that saving LUTs is more
important than than saving block ram.
-- Mike Treseler
Article: 141603On Jun 29, 2:35=A0pm, Benjamin Couillard <benjamin.couill...@gmail.com> wrote: > Hi, > > I have a problem with dual-port ram inference. I have a module called > "dual_port_ram.vhd" that I use to infer a dual port ram. This file is > based on Xilinx template and it works well almost everytime. > > My problem is the following, I have a module called "widget.vhd" that > instantiates a 1024x20 bit dual-port ram. When I synthesize > widget.vhd, I see that ISE correctly inferred the =A0dual-port ram with > 2 block rams. > > I have another VHDL module called "gadgets.vhd" that instantiates 4 > "widget.vhd" components. We should expect ISE to synthesize > "gagdets.vhd" with 8 block rams. > > However, when I synthesize "gadgets.vhd", ISE infers the 4 1024x20 bit > dual-port ram in distributed logic instead of using 8 block rams. I > have enough block rams in my device for the instantiation so it's not > some kind of fallback plan by ISE synthesis. What's even weirder is > that when I add the "keep_hierarchy" attribute in "widget.vhd", ISE > will synthesize "gagdets.vhd" with 8 block rams instead of > synthesizing it with 4 1024x20bit distributed logic ram. > > Does anyone here have some kind of explanation? > > I use ISE 11.1 with resource sharing disabled. > > Best regards > > Benjamin You didn't post the template, but I've seen some that don't really match the RAM architecture. Instead of placing a register on the read output data, it places the register on the read address. Then it fails to map to block RAM, but only if it shares the registered read address between RAM blocks. I would expect the Xilinx templates to work correctly, but in case you are not using the latest one, this is something to check. Regards, GaborArticle: 141604
On Jun 29, 3:35=A0pm, gabor <ga...@alacron.com> wrote: > On Jun 29, 2:35=A0pm, Benjamin Couillard <benjamin.couill...@gmail.com> > wrote: > > > > > > > Hi, > > > I have a problem with dual-port ram inference. I have a module called > > "dual_port_ram.vhd" that I use to infer a dual port ram. This file is > > based on Xilinx template and it works well almost everytime. > > > My problem is the following, I have a module called "widget.vhd" that > > instantiates a 1024x20 bit dual-port ram. When I synthesize > > widget.vhd, I see that ISE correctly inferred the =A0dual-port ram with > > 2 block rams. > > > I have another VHDL module called "gadgets.vhd" that instantiates 4 > > "widget.vhd" components. We should expect ISE to synthesize > > "gagdets.vhd" with 8 block rams. > > > However, when I synthesize "gadgets.vhd", ISE infers the 4 1024x20 bit > > dual-port ram in distributed logic instead of using 8 block rams. I > > have enough block rams in my device for the instantiation so it's not > > some kind of fallback plan by ISE synthesis. What's even weirder is > > that when I add the "keep_hierarchy" attribute in "widget.vhd", ISE > > will synthesize "gagdets.vhd" with 8 block rams instead of > > synthesizing it with 4 1024x20bit distributed logic ram. > > > Does anyone here have some kind of explanation? > > > I use ISE 11.1 with resource sharing disabled. > > > Best regards > > > Benjamin > > You didn't post the template, but I've seen some that don't > really match the RAM architecture. =A0Instead of placing a > register on the read output data, it places the register > on the read address. =A0Then it fails to map to block RAM, > but only if it shares the registered read address between > RAM blocks. =A0I would expect the Xilinx templates to work > correctly, but in case you are not using the latest one, > this is something to check. > > Regards, > Gabor Here's my "dual_port_ram.vhd" library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity dual_port_ram is generic (width : integer :=3D 16; addr_width : integer :=3D 7); port(clka : in std_logic; clkb : in std_logic; ena : in std_logic; enb : in std_logic; wea : in std_logic; web : in std_logic; addra : in std_logic_vector(addr_width-1 downto 0); addrb : in std_logic_vector(addr_width-1 downto 0); dia : in std_logic_vector(width-1 downto 0); dib : in std_logic_vector(width-1 downto 0); doa : out std_logic_vector(width-1 downto 0); dob : out std_logic_vector(width-1 downto 0)); end dual_port_ram; architecture syn of dual_port_ram is type ram_type is array (2**addr_width-1 downto 0) of std_logic_vector (width-1 downto 0); shared variable RAM : ram_type :=3D (others =3D> (others =3D> '0')); -- begin process (CLKA) begin if (rising_edge(CLKA)) then if ENA =3D '1' then DOA <=3D RAM(to_integer(unsigned(ADDRA))); if WEA =3D '1' then RAM(to_integer(unsigned(ADDRA))) :=3D DIA; end if; end if; end if; end process; process (CLKB) begin if (rising_edge(CLKB)) then if ENB =3D '1' then DOB <=3D RAM(to_integer(unsigned(ADDRB))); if WEB =3D '1' then RAM(to_integer(unsigned(ADDRB))) :=3D DIB; end if; end if; end if; end process; end syn;Article: 141605
Sudhir One other Xilinx advantage can be the SRL16 construct where the LUT is used as a shift register rather than just a ram. The SRL16 alone can shrink some designs by a lot if the design can make use of it. For boards in 4 months Spartan-6 would be very difficult to get, if not impossible, and Spartan-3 is the way for a Xilinx offering in that timeframe. John Adair Enterpoint Ltd. - Home of Darnaw1 the FPGA PGA Solution. On 29 June, 14:05, Sudhir Singh <Sudhir.Si...@email.com> wrote: > Hi Guys, > Thanks for your replies. > > John, its interesting that you suggested Spartan-3A DSP and Spartan-6 > coz I had enquired with a distributor about these two devices just > today. Hopefully Spartan-3A DSP will have a good pricing. > We have to have the boards fabricated in 4 months time so Spartan-6 > may be no-goer at this stage. > > I didn't realise that CIII's LUTs can not be configured as distributed > memory. > > Cheers > SudhirArticle: 141606
Hi, does anybody know an existing SATA Phy that can interface to Spartan 3E FPGAs? And of course can be bought in smaller volume. Thanks ThomasArticle: 141607
sanika wrote: > Thanks > But what could be the reason for program fail..Is CPLD faulty in that > case? No. The message is saying that it can not find any test patterns to check the chip against, therefore the functional test cannot be performed. JonArticle: 141608
On Jun 29, 7:35=A0am, radarman <jsham...@gmail.com> wrote: > On Jun 28, 4:45=A0pm, james <geo...@washington.edu> wrote: > > > > > On Sun, 28 Jun 2009 06:42:25 -0700 (PDT), > > > "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > > > |On Jun 28, 3:42=A0pm, CMOS <manusha1...@gmail.com> wrote: > > |> hi, > > |> im plannining to buy a vertex 2 based FPGA board. this is the link. > > |> > > |>http://www.digilentinc.com/Products/Detail.cfm?NavPath=3D2,400,453&Pr= od... > > |> > > |> does this board worthy for the price of $299? > > |> > > |> CMOS > > | > > |absolutly, if you get it for $299! > > | > > |too bad Xilinx is no longer supporting Virtex-II with their ISE > > | > > |ISE 10.1 is the last version that offered V-II support, > > | > > |Antti > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > $299 is the acedemic pricing. > > > james > > I really wish more companies didn't specifically target "academic", > and would offer a more broad "non-industrial" price. I'm not in > college anymore, but I still try to keep my skills honed at home - > thus, I don't have a student ID, but I still consider myself to be a > "student". That's the problem when your a "hobbiest". You don't get any of the breaks that you got as a student and the IRS frowns on letting you write off any of your toys. Bummer. I do have a couple of digilent boards and they are quality products. They are a good deal if you can get the academic price.Article: 141609
On Jun 29, 2:27=A0pm, Thomas Rudloff <thomasREMOVE_rudloffREM...@gmx.net> wrote: > Hi, > > does anybody know an existing SATA Phy that can interface to Spartan 3E > FPGAs? And of course can be bought in smaller volume. > > Thanks > Thomas Marvell sells SAS/SATA phys for ~ $140 a piece. I don't think you'd find those on the website. Better contact sales rep. - Evgeni http://OutputLogic.comArticle: 141610
Hello, we in our lab just got a ML405 board...i wanted to implement a program from the compact flash on to the FPGA., the problem arrived when i tried a format of the compact flash using mkdosfs as specified by Xilinx (as described in Answer Records #14456) afterwards i but the bitstream (consisting of the combined hardware + software parts as created by data2mem).. on the compact flash.. but when i insert the compact flash on the board and power it on.. the red error light starts blinking .. i checked the system ace switches and they are correctly aligned.. the first three are on the bottom position (inactive) and the last three are on the top position (active).. I even tried to reformat the card with its original contents using the method defined in the Xilinx china's website ... but still the same problem.. I also followed the example in http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=25046 but that didn't work also.. I need help as i don't know how to program the ML405 by the system ace :(....Article: 141611
i need to interface a nor flash with spartan 3, basically plan on running a soft micro controller in the fpga and need a flash for code memory. now searching mouser and digikey i wasn't able to find a lot, there is p33 by numonyx, but i was looking for a model which has alteast a couple of pin compatible devices for future compatibility if one stops manufacturing. can any one please help me out over here regardsArticle: 141612
http://lmgtfy.com/?q=nor+flash+manufacturersArticle: 141613
On Jun 27, 9:13=A0pm, "Fredxx" <fre...@spam.com> wrote: > "Mike Treseler" <mtrese...@gmail.com> wrote in message > > news:7akg5eF1tmmprU1@mid.individual.net... > > > Fredxx wrote: > > >> At the same time blind reliance of simulators is just as bad. > > > As is blind reliance on anything. > > >> There is the old saying garbage in =3D garbage out. > > > An rtl sim is a pretty good garbage filter. > > It is only sufficient with a well-tested set of design rules. > > Hmm - perhaps you're interfacing with an external IC. =A0Are you going to= tell > me you'd blindly write a testbench without confirming that your interface= in > real hardware is correctly understood? > > It's clear you've never got a PCI or PCIe interface working without > resorting to the likes of chipscope, where reality doesn't even match > signals as per standards. > > > > >> In the past I have also come across instances where simulation has tak= en > >> so > >> long, and created such large files, that reality has been quicker with= a > >> few > >> debugging flags in the code! > > > I have worked on projects where a few debugging > > flags in the code would never have found > > all of the logical errors. > > Couldn't agree more. > > > > > A good testbench doesn't produce large files. > > I was thinking of waveform files, where perhaps the simulation has to fir= st > wade though a million states to start providing data. > > > It reports pass or fail. > > You're just not living in the real world of FPGA design which ought to be= a > mix of simulation and reality. =A0Anything else, and you are either assum= ing > your test bench doesn't have any flaws, or just fumbling in the dark. Nobody is saying you never have to test a design in the chip. I think Mike is just saying that time spent on a good test bench is work many more hours in the lab with an O-scope. I know that my designs typically are much harder to debug on the bench than in simulation. I seldom get my test benches honed to the point of giving me a pass/fail indication, but I know that I am going to be running them many more times than once and construct them accordingly. In fact, I typically design a test bench for each module and unit test before I integrate. If the module changes during integration, I rework the unit test bench to keep up with the changes. This can add greatly to module reuse as well as helping to keep the bulk of debugging at a lower level where it is easier to find and repair bugs. The software community has a lot of good ideas that *do* apply to writing HDL code. We just need to consider these ideas and use them appropriately. RickArticle: 141614
On Jun 24, 3:15=A0pm, recoder <kurtulmeh...@gmail.com> wrote: > =A0We are used to process 70 Mhz IF by using ADC boards to interface to > our fpga boards. > Now we have to process the following signal: > 720 Mhz IF > qpsk modulated > =A080 mhz bandwith (3 dB) > > Can anybody recommend a board to interface the 720 Mhz IF to a FPGA > board? Have you looked at boards with TI's ADS5474 ADC? It has a max sample rate of 400 MHz and a 1.4 GHz input bandwidth. Maybe it doesn't meet your SNR requirements at 720 MHz IF, but it's worth a look. Darol KlawetterArticle: 141615
Hi, found two tools for Verilog which is supposed to keep documentation and implementation of control and status registers in sync. Vregs on www.veripool.com and csrGen.pl on asics.chuckbenz.com. (Actually csrGen.pl was not downloadable due to an internal error, but the documentation made it look interesting). I also found a commercial tool from PDTi which is probably doing the same but I haven't got as far as getting a demo license. So far the documentation of the register map is in Word. Many pages with text and tables and functional description that needs to be kept in sync. Currently a reorganization of this register map is happening in OpenOffice calc to be able to see the bits and pieces of the register map, and to be able to move them around. The VHDL code is then modified manually according to the spreadsheet and the Word document is then modified again. In the end the application programmer is going to take that Word document and type a lot of #defines in his C-files and I bet we will spend some weeks looking for those nasty bugs that all this manual work will produce. The project is running on an FPGA so it is too easy to just add registers and bits as new features come up, or to move them when they doesn't fit the access model of the application that is later going to access the registers (via PCI) Vregs solves this problem by creating VHDL and C-headers from HTML exported from a text processor that can export HTML. csrGen.pl will take input from a definition file. I found both solutions charming, except from the fact that they generate Verilog instead of VHDL, and that one wasn't available anymore. I'm wondering how other VHDL programmers solve their CSR bookkeeping, or maybe there is a tool out there that I haven't found. It doesn't need to be open source, if it is any good we will buy it. From the efforts by Wilson Snyder on Vregs I take that this is not a tool that I can write overnight myself. Maybe it is portable since it is written in perl, but Verilog and VHDL does think differently, and I am not a perl savvy. (Can't even read my own code after six weeks) -- SvennArticle: 141616
Svenn Are Bjerkem wrote:
> I'm wondering how other VHDL programmers solve their CSR bookkeeping,
> or maybe there is a tool out there that I haven't found.
I don't automate any process until I've proven to
myself that the manual process warrants the automation time.
If I did decide to automate register documentation, I think I would
make the script read my code, not write it.
I would also make sure there was an audience for my pretty printing,
before I went to the trouble generating it.
-- Mike Treseler
Article: 141617On May 20, 10:53=A0pm, David Antliff <david.antl...@gmail.com> wrote: > On May 21, 3:37=A0pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > > > Are you sure that the settings you are using are identical. =A0I was un= der > > the impression that ISE was just a GUI wrapper that sent commands to a = common > > set of implementation programs. > > Hi Matthew, > > I'm working with Andrew on this project. > > The settings are not identical because ngdbuild.exe invoked by ISE has > an '-ise project.ise' and '-intstyle ise' options. We want to avoid > the use of the .ise project file entirely. > > Also it seems that the GUI calls a different set of executables in the > "unwrapped" subdirectory of "ISE/bin/nt". It also passes the ISE > project file as a parameter and there's evidence that some settings > (such as the UCF file) are drawn from this. As I mention later, > running the same executable as the ISE generates a strange fatal > exception. > > Let me try and describe the issue fully. > > =A0- we are using Xilinx 10.1 service pack 3 on Windows XP, and a recent > installation of Cygwin. > =A0- we are trying to incorporate Xilinx into our automated build system > - so we are running the Xilinx command-line applications from a GNU > Makefile invoked from a Cygwin bash shell. > =A0- we want to avoid the project .ise file completely as this seems to > change every time anyone opens it - this makes build tracking > difficult and therefore the .ise file is unsuitable as an input to our > automated build process. > =A0- we first synthesize an EDIF file with Synplify 9.6.2 - this is > called FPGA_DAC16V2.edf in the examples below > =A0- the Xilinx Project Navigator ISE file contains just two sources: > =A0 =A0 FPGA_DAC16V2.edf > =A0 =A0 Constraints/FPGA_DAC16V2.ucf > > Once we have our EDIF, we wanted to see how to drive the Xilinx > Translate process (ngdbuild.exe) from the command line: > > =A0- the <project>.cmd_log file that Project Navigator creates during > Translate shows ngdbuild executing as follows: > > ngdbuild -ise "D:/DAC_16v2/FPGA_DAC16V2/PAR/FPGA_DAC16V2/ > FPGA_DAC16V2.ise" -intstyle ise -dd _ngo =A0-nt timestamp -i -p xc3s1000- > ft256-4 "D:/DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/ > FPGA_DAC16V2.edf" FPGA_DAC16V2.ngd > > =A0- hmm, there are two 'ngdbuild.exe' programs under .../ISE/bin/nt - > which one is being run? We think it's 'bin/nt/unwrapped/ngdbuild.exe'. > =A0- anyway, we note the '-i' option means 'ignore the User Constraints > File', although the log output shows: > =A0 =A0 ... > =A0 =A0 Reading in constraint information from 'Constraints/ > FPGA_DAC16v2.ucf'... > > =A0 =A0 ... > > =A0- we believe ngdbuild is picking up the presence of this UCF file > from the referenced .ise file, but perhaps not actually applying the > constraints due to -i option. > =A0- now, because we want to remove the .ise file from our process, we > manually converted this into the following command using "xflow" > integration: > > D:/Xilinx/10.1/ISE/bin/nt/ngdbuild.exe -intstyle xflow -dd _ngo =A0-nt > timestamp -i -p xc3s1000-ft256-4 > "D:/DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/ > FPGA_DAC16V2.edf" FPGA_DAC16V2.ngd > > However the log output from this shows that this time, the constraint > information is not read, presumably because ngdbuild does not know > about the UCF file. This also results in a file about 100kb smaller > than the ISE generated .ngd file - certainly a different output. If > the entire process is run to generate a .bit file, a binary diff shows > these two .bit files as *significantly* different. > > =A0- so we determine that the UCF is probably required, changing the > command line to (replacing -i with -uc <file>): > > D:/Xilinx/10.1/ISE/bin/nt/ngdbuild.exe -intstyle xflow -dd _ngo =A0-nt > timestamp -uc Constraints/FPGA_DAC16V2.ucf -p xc3s1000-ft256-4 "D:/ > DAC_16v2/FPGA_DAC16V2/Synthesis/FPGA_DAC16V2/rev_1/FPGA_DAC16V2.edf" > FPGA_DAC16V2.ngd > > HOWEVER > > Instead of "Reading in constraint information from 'Constraints/ > FPGA_DAC16v2.ucf'..." we see this instead: > > ... > Applying constraints in "d:/DAC_16v2/FPGA_DAC16V2/PAR/FPGA_DAC16V2/ > Constraints/FPGA_DAC16V2.ucf" to the design... > ... > > This is not what the ISE flow said it was doing. It read the UCF file > but it certainly didn't say it was applying the constraints! > > Not only this, but the resulting .ngd file is still different - in > this case, the ISE generated .ngd file is 5333871 bytes and the one > generated by the commandline is only 5333798 bytes, or 73 bytes > smaller. A binary diff shows the files are almost entirely different. > This results in all other files beyond ngdbuild (such as map, par, > etc) to be different too. And the problem is, we don't know what is > actually different! > > Interestingly, although all the resulting intermediate files that > follow on from this are different between the two processes, the > final .bit file is thankfully identical except for a few bytes that > look like a timestamp near the top of the file. This is a huge relief! > However we would still like to know what is going on because if we > can't generate identical ngd files, or at least be sure that they > differ only by a timestamp, then building confidence in our build > system will be difficult. Who is to say that future builds will > deviate in unknown ways? > > We would like the output from ISE to exactly match the output from the > commandline, and if this is not possible then we'd like to know why > the two output files differ. > > This raises a few questions: > > 1. is the .ngd output file encrypted or perhaps compressed? This would > explain the massive difference in the two files, especially if there's > a timestamp embedded in them. > > 2. how can we get the output .ngd files to be the same without > referencing the .ise file - what are we missing on the command line? > > 3. why does the ISE flow appear to not apply the UCF constraints, yet > if we don't do this with our command-line build, the resulting .bit > file is completely different. > > 4. why does the .ise Project file continually change? Even running > 'ngdbuild -ise FPGA_DAC16V2.ise -h' to display the program's HELP text > causes the .ise file to change! Why? This makes it very difficult to > manage in a Source Control tool because it's continually changing > without a clear reason. > > 5. what is the difference between the file .../ISE/bin/nt/ngdbuild.exe > and .../ISE/bin/nt/unwrapped/ngdbuild.exe? The 'unwrapped' version of > ngdbuild.exe is used by ISE but when used in the example command-lines > above it frequently fails to find the UCF file and aborts: > > ERROR:ProjectMgmt:356 - Problem loading constraints. > ... > FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:143:1.6 - This > application > =A0 =A0has discovered an exceptional condition from which it cannot > recover. > =A0 =A0Process will terminate. For technical support on this issue, pleas= e > open a > =A0 =A0WebCase with this project attached athttp://www.xilinx.com/support= . > > I assume from this that we are not supposed to be calling the > 'unwrapped' version of the exe file? Perhaps this is for internal ISE > use only? > > So it appears it is not possible to run a). the same ngdbuild > executable, or b). the same command line options if you want to > completely avoid referencing the ISE project file with a command-line > invocation of ngdbuild. > > -- David Antliff An ISE 10.x or 11.x project might have multiple UCF files. But the ngdbuild is allowed only a single UCF as a parameter. I was told by Xilinx tech support that ISE concatenates all included UCFs into a single temp file and uses it to pass to ngdbuild. So if you build such a project from a script, you shouldn't forget to concatenate all the UCFs yourself. - Evgeni http://OutputLogic.comArticle: 141618
Hi, I would like to know the flow (either for Altera or Xilinx) to freeze the FPGA pinout before the P&R phase is complete. One safe assumption is that all timing issue will be taken care inside of the FPGA without any changes to the pinout. Regards,Article: 141619
http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.html#wp244527Article: 141620
On Jul 1, 6:05=A0am, "Symon" <symon_bre...@hotmail.com> wrote: > http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm... I've always used the NET keyword, as opposed to PIN, e.g.: NET top_level_port_name LOC =3D "A23"; I'm not sure about the assumption that all the timing issues will be taken care of by the tools, though. Letting the tools choose the pinout, and then locking them down, might be safer.Article: 141621
On Jul 1, 3:05 pm, "Symon" <symon_bre...@hotmail.com> wrote: > http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm... Thanks, but I was not asking about the setting up the constraints for fpga pinouts, it was a larger question. How do I ensure that I have got a fairly accurate pinout (assuming meeting timing is not an issue) when the design is still under development. Do people create dummy FPGA top and use special tools that only check the validity of the pinouts wrt to the selected device? Look at it this way - people in S/W world exchange information about each other's module by providing the class prototypes and this happens much before the code has been developed. Regards,Article: 141622
On Jul 1, 9:40=A0am, Sharanbr <sharan.basa...@gmail.com> wrote: > On Jul 1, 3:05 pm, "Symon" <symon_bre...@hotmail.com> wrote: > > >http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm... > > Thanks, but I was not asking about the setting up the constraints for > fpga pinouts, it was a larger question. > How do I ensure that I have got a fairly accurate pinout (assuming > meeting timing is not an issue) when > the design is still under development. Do people create dummy FPGA top > and use special tools that only > check the validity of the pinouts wrt to the selected device? > > Look at it this way - people in S/W world exchange information about > each other's module > by providing the class prototypes and this happens much before the > code has been developed. > > Regards, You should look at the datasheet and user guide for the device you're using, and understand the functionality of the different types of pins it has. Then, you can start deciding which pins can go where. Board layout concerns and I/O standards come into play as well.Article: 141623
Sharanbr escribió: > On Jul 1, 3:05 pm, "Symon" <symon_bre...@hotmail.com> wrote: >> http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm... > > Thanks, but I was not asking about the setting up the constraints for > fpga pinouts, it was a larger question. > How do I ensure that I have got a fairly accurate pinout (assuming > meeting timing is not an issue) when > the design is still under development. Do people create dummy FPGA top > and use special tools that only > check the validity of the pinouts wrt to the selected device? > > Look at it this way - people in S/W world exchange information about > each other's module > by providing the class prototypes and this happens much before the > code has been developed. > > Regards, In XILINX, PACE or PLANAHEAD, allow you to define your pintout and do a basic ERC, but beware you must use good placement rules or you fall into implementations errors after; WalterArticle: 141624
It is really possible to use FPGA to generate FM Radio signal DIRECTLY in most cases there radio will pickup signal from PCB trace already i did only a very little experiments (wrote in june issue also a little) even using audio signal to invert phase will produce signal that is received as FM modulation (with low modulation index) using simple NCO gives much better results. Antti
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