Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 141600

Article: 141600
Subject: Re: STA Problem on Asynchronous FIFO
From: vcar <hitsx@163.com>
Date: Mon, 29 Jun 2009 09:15:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: dual port inference problem
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Mon, 29 Jun 2009 11:35:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Benjamin

Article: 141602
Subject: Re: dual port inference problem
From: Mike Treseler <mtreseler@gmail.com>
Date: Mon, 29 Jun 2009 12:24:45 -0700
Links: << >>  << T >>  << A >>
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: 141603
Subject: Re: dual port inference problem
From: gabor <gabor@alacron.com>
Date: Mon, 29 Jun 2009 12:35:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.  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,
Gabor

Article: 141604
Subject: Re: dual port inference problem
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Mon, 29 Jun 2009 12:48:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Spartan3E or Cyclone III ?
From: John Adair <g1@enterpoint.co.uk>
Date: Mon, 29 Jun 2009 14:23:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
> Sudhir


Article: 141606
Subject: SATA Phy
From: Thomas Rudloff <thomasREMOVE_rudloffREMOVE@gmx.net>
Date: Mon, 29 Jun 2009 23:27:22 +0200
Links: << >>  << T >>  << A >>
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

Article: 141607
Subject: Re: Error while downloading prodram on CPLD
From: Jon Elson <jmelson@wustl.edu>
Date: Mon, 29 Jun 2009 17:31:44 -0500
Links: << >>  << T >>  << A >>
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.

Jon

Article: 141608
Subject: Re: usefulness of Virtex-II devices
From: John Eaton <z3qmtr45@gmail.com>
Date: Mon, 29 Jun 2009 16:53:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: SATA Phy
From: OutputLogic <evgenist@gmail.com>
Date: Mon, 29 Jun 2009 19:51:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.com

Article: 141610
Subject: Formatting ML405 system compact flash card.;
From: iquadri <iquadri@gmail.com>
Date: Tue, 30 Jun 2009 04:01:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: help needed regarding NOR Flash
From: Nashit Ashraf <mnashi@gmail.com>
Date: Tue, 30 Jun 2009 04:18:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

regards

Article: 141612
Subject: Re: help needed regarding NOR Flash
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 30 Jun 2009 13:49:24 +0100
Links: << >>  << T >>  << A >>
http://lmgtfy.com/?q=nor+flash+manufacturers



Article: 141613
Subject: Re: True dual-port RAM in VHDL: XST question
From: rickman <gnuarm@gmail.com>
Date: Tue, 30 Jun 2009 07:24:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 141614
Subject: Re: 720 Mhz IF Processing
From: Darol Klawetter <darol.klawetter@l-3com.com>
Date: Tue, 30 Jun 2009 12:10:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Klawetter

Article: 141615
Subject: How to keep documentation of control and status registers and VHDL
From: Svenn Are Bjerkem <svenn.bjerkem@googlemail.com>
Date: Tue, 30 Jun 2009 13:24:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
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)

--
Svenn

Article: 141616
Subject: Re: How to keep documentation of control and status registers and
From: Mike Treseler <mtreseler@gmail.com>
Date: Tue, 30 Jun 2009 14:42:25 -0700
Links: << >>  << T >>  << A >>
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: 141617
Subject: Re: Can we expect ISE Gui and makefile to produce identical bit
From: OutputLogic <evgenist@gmail.com>
Date: Tue, 30 Jun 2009 18:33:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 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.com




Article: 141618
Subject: pinout
From: Sharan <sharan.basappa@gmail.com>
Date: Tue, 30 Jun 2009 23:59:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: pinout
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 1 Jul 2009 11:05:43 +0100
Links: << >>  << T >>  << A >>
http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.html#wp244527 



Article: 141620
Subject: Re: pinout
From: Dave <dhschetz@gmail.com>
Date: Wed, 1 Jul 2009 06:37:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: pinout
From: Sharanbr <sharan.basappa@gmail.com>
Date: Wed, 1 Jul 2009 06:40:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: pinout
From: Dave <dhschetz@gmail.com>
Date: Wed, 1 Jul 2009 07:01:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: pinout
From: Walter <wsfpga@adinet.com.uy>
Date: Wed, 01 Jul 2009 11:02:10 -0300
Links: << >>  << T >>  << A >>
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;

Walter


Article: 141624
Subject: FPGA as FM RADIO transmitter
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 1 Jul 2009 08:11:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search