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 72600

Article: 72600
Subject: EPM7064LC44-7 - Not there in Quartus II...
From: dhruvish@gmail.com (Drew)
Date: 26 Aug 2004 05:41:41 -0700
Links: << >>  << T >>  << A >>
Hello guys,

I am trying to Assign the Max Family EPLD - EPM7064 LC44-7 and run my
compilation. But in the Assign Device I find EPM7064 SLC44-7. There
are some significant differences between LC and SLC in terms of Max
allowable freq, LCELL delay etc. Please let me know if anybody can
find it in the Assign Device section.

Thanks
Drew

Article: 72601
Subject: Re: JTAG software
From: "Ted" <ted@ted.com>
Date: Thu, 26 Aug 2004 14:43:28 +0100
Links: << >>  << T >>  << A >>

"FatBoySlim" <fatboyslim123@softhome.net> wrote in message
news:4182a556.0408260015.5cac5b85@posting.google.com...
> From where can i get a JTAG software .
> I have a FPGA chip and configuration bit file.
> So how shall i load the bits to FPGA chip

I use iMPACT, which comes with the free version of Xilinx ISE 4.2i.  I guess
it's also included with the Xilinx WebPack, which is also free.  You can
download it from www.xilinx.com.



Article: 72602
Subject: Re: 6.1 vs. 6.2
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 26 Aug 2004 07:19:09 -0700
Links: << >>  << T >>  << A >>
Johan Bernspång wrote:

> Mike, in my application it is quite hard to generate a proper test
> vector (FM-modulated radio signal), whereas doing logic analysis using a
> real radio or a signal generator as input is straight forward and gives
> good insight on what's happening in the system.

HDL simulation has a steep learning curve, but
the advantages include quick regression for
design changes and better coverage of corner cases.

> As far as I'm aware, the design is fully synchronous. How would
> synchronous design be an alternative to logic analysis? 

*Simulation* is an alternative to logic analysis.
For synchronous designs, a functional sim and
Xilinx static timing are all the chipscope you need.

 -- Mike Treseler

Article: 72603
Subject: Re: DSP/FPGA/video board?
From: johnjakson@yahoo.com (john jakson)
Date: 26 Aug 2004 07:22:27 -0700
Links: << >>  << T >>  << A >>
"Georgi Beloev" <gbH8SPAM@beloev.net> wrote in message news:<SYydnTMglL5u-7fcRVn-gw@megapath.net>...
> Hi,
> 
> I'm looking for an inexpensive (up to $1000) development board with the
> following features:
> 
> - Relatively fast DSP, e.g., Blackfin.
> - Mid-range Cyclone II or Spartan-3 FPGA.
> - At least 4 MB SDRAM.
> - Video in (CVBS and Y/C), digital video decoder.
> - Video out (CVBS and Y/C),  digital video encoder.
> - The video decoder and encoder should be able to work simultaneously.
> 
> A combination of boards, e.g., a DSP kit and a plug-in FPGA board can also
> work. Other DSPs and FPGAs than the ones mentioned above can also be
> considered. This is for doing research on video processing and video
> compression; I don't have more precise requirements yet.
> 
> Thanks,
> -- Georgi

Usual place to start is

http://www.fpga-faq.com/FPGA_Boards.shtml

Nallatech comes to mind but there are a few others that do DSP+FPGA too.

Google <dsp fpga video boards> gives me plenty to start by 
$1k is cutting it on the low side for some of these vendors.



http://www.entegra.co.uk/c6416_pmc_fpga_dsp_quadia.htm

http://www.nuhorizons.com/products/xilinx/DSP/index.html

http://www.lyrtech.com/DSP-development/educational/index.php

http://www.traquair.com/catalog/microline.products.html

http://www.mangodsp.com/

http://www.hunteng.co.uk/solutions/imagesys.htm


and so on

regards

johnjakson_usa_com

Article: 72604
Subject: Re: X propagation in Timing Simulation
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 26 Aug 2004 10:44:12 -0400
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> 
> It would be better if the FF model should do rather more
> accurate modelling of metastability: the output should go
> to X, then after some settling time it should go to a
> random choice of 0 or 1.  Once you have decided to do this,
> it's easy to make the model even more accurate:  use the
> precise time of the setup violation to determine how long
> the settling time should be, and to bias the random choice
> of 0/1.  However, if you do this, the FF model will probably
> become very inefficient and slow to simulate; so, once
> again, you should apply this model only to the resynch
> FFs.

I think the value of the more complex model is very limited and may even
be counter productive.  Accurate models are nice, but it would be very
hard to do anything useful with modeling metastability rates since a
failure of once a month is typically not good enough.  Would anyone be
willing to run a month long simulation?  That would take, what, a couple
of years?  

It is likely better to pick a settling time and to model that.  Or even
better to analyze metastability in static timing analysis.  

My suggestion is to go with the minimal model that ignores setup
violations and not model metastability in simulation.  Static timing
analysis is the correct tool to analyze metastability.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 72605
Subject: Xilinx Command Prompt
From: "Ted" <ted@ted.com>
Date: Thu, 26 Aug 2004 15:45:05 +0100
Links: << >>  << T >>  << A >>
Hi,

I'm trying to run the Xilinx toolset from the MS-DOS command prompt.
Ultimatly I plan to do all of my VHDL design in Linux using WINE, but before
I do that I want to get the commands working in MS-DOS.  The Xilinx software
I'm using is ISE 4.2i.  For the first test I have created the following VHDL
code (called source.vhd):

/********************************************/
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity source is
    Port ( a : in std_logic;
         b : out std_logic );
end source;

architecture Behavioral of source is
begin
 b <= not a;
end Behavioral;
/********************************************/

And I also have a constraints file, which is called source.ucf.  That file
contains:

/********************************************/
NET "a" LOC = "p57";
NET "b" LOC = "p82";
/********************************************/

To see what is involved, I first used the Project Navigator to implement the
design in my FPGA.  I could then look at the log files to see what commands
I needed to run and in what order.  The commands I ran are (the rsp files
are the one's generated by Project Navigator):

XST -ifn source.xst
NGDBUILD -f __ngdbuild.rsp
MAP -f _map.rsp
PAR -f _par.rsp   (I changed this file)

The file _par.rsp contained the following text:


/********************************************/
-ol 2
-xe 0
-t 1
-c 0
par_temp.ncd
-w
source.ncd
source.pcf
/********************************************/

As I do not have a file called par_temp.ncd I deleted that line from the
_par.rsp file (could that be the cause of my problem).

My next step was to run bitgen to create the programming file, but when I
ran it I got the following error:

/********************************************/
Running DRC.
ERROR:DesignRules:542 - Netcheck: Design has unrouted nets - 1 unrouted net
   warnings are not reported.
ERROR:DesignRules:14 - Blockcheck: The component "a" has not been placed.
ERROR:DesignRules:14 - Blockcheck: The component "b" has not been placed.
WARNING:Bitgen:25 - DRC detected 3 errors and 1 warnings.
/********************************************/

It looks to me like my constraints file is not being used.  Is this the
case?  If so, what have I done wrong and how can I tell the Xilinx toolset
to use my constraints file?  If you need anymore info just say.


Thanks for any help,



Article: 72606
Subject: Re: X propagation in Timing Simulation
From: Jonathan Bromley <jonathan.bromley@doulos.com>
Date: Thu, 26 Aug 2004 16:02:14 +0100
Links: << >>  << T >>  << A >>
On Thu, 26 Aug 2004 10:44:12 -0400, 
rickman <spamgoeshere4@yahoo.com> wrote:

>Jonathan Bromley wrote:
>> 
>> It would be better if the FF model should do rather more
>> accurate modelling of metastability: the output should go
>> to X, then after some settling time it should go to a
>> random choice of 0 or 1.  Once you have decided to do this,
>> it's easy to make the model even more accurate:  use the
>> precise time of the setup violation to determine how long
>> the settling time should be, and to bias the random choice
>> of 0/1.  However, if you do this, the FF model will probably
>> become very inefficient and slow to simulate; so, once
>> again, you should apply this model only to the resynch
>> FFs.
>
>I think the value of the more complex model is very limited and may even
>be counter productive.  Accurate models are nice, but it would be very
>hard to do anything useful with modeling metastability rates since a
>failure of once a month is typically not good enough.  Would anyone be
>willing to run a month long simulation?  That would take, what, a couple
>of years?  
>
>It is likely better to pick a settling time and to model that.  Or even
>better to analyze metastability in static timing analysis.  

I wholeheartedly agree that theoretical analysis is the right 
approach - especially for things like this where, as you 
correctly say, it is absurd to expect simulation to detect
every possible failure.  On the other hand, it's nice to
know that you *can* realistically model metastability effects.
If such modelling has any value, it is much the same kind of
value as modelling a short nominal clock-to-output delay on
flip-flops in RTL simulations - it makes real behaviour
much easier to visualise.  It also makes the simulation 
easier to believe, especially for project managers who are
paranoid about metastability but don't understand it :-)

>My suggestion is to go with the minimal model that ignores setup
>violations and not model metastability in simulation.

On balance, I think I probably agree.

> Static timing analysis is the correct tool to analyze metastability.

Agreed, without reservation.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223          mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 72607
Subject: Re: X propagation in Timing Simulation
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Thu, 26 Aug 2004 09:48:39 -0600
Links: << >>  << T >>  << A >>


Jonathan Bromley wrote:
> On 26 Aug 2004 03:30:22 -0700, muthusnv@yahoo.co.in (Muthu) wrote:
> 
> 
>>In a timing simulation, Setup / Hold violation of Flip-Flop will
>>result in value of 'x' at the output. Is that Right?
> 
> 
> Usually so.  It depends on how the model was written.  Most FF
> models (in Verilog at least) put X on the output if there's a
> violation.  This X will presumably be corrected on the next
> clock edge, unless there's another timing violation there.


This is the default behavior is most timing simulation models, including 
Xilinx's.  There is a better way to get around this though.  For Xilinx 
simulations, if you place the attribute ASYNC_REG=TRUE on the offending 
FF, it will disable the X-propagation for that particular FF in timing 
simulation.  You will see see timing warnings generated as a timing 
violation is still occurring however the behavior of the FF during a 
timing violation is changed to that it keeps its previous value rather 
than going to X.  Keep in mind that the FF may have gone metastable or 
resulted in a changed value so that must be weighed in for simulation 
but this will allow for a more usable behavior for simulation if this 
situation occurs.


> 
>>If so, how double synchronisation circuits work in timing simulation ?
>>Won't it propagate x. ?
> 
> 
> Yes - at least for one clock cycle.  Tedious stuff.
> 
> Most people fake their way around this by replacing the first 
> FF model in the resynchroniser with a FF model that doesn't
> propagate X.  In most cases there are very few FFs that need
> to be modified in this way, so it's not very hard to do.  
> And we hope that you have analysed your resynchroniser 
> very carefully, so you are happy to accept the poor 
> modelling because you already know (from the analysis) 
> exactly how the resynchroniser behaves in all cases.


If using Xilinx, rather than doing this, just put an ASYNC_REG=TRUE on 
the first synchronization FF.  It is not necessary on the second as it 
will not see a timing violation as long as the route is not too long for 
it from the first.  If it is, you would want to know about that and 
likely correct that so it generally is not a good idea to put it on the 
second synchronizing register.  That attribute can be put on either an 
instantiated or inferred register and can be put either in the code 
itself (that is how I like to do it) or in the UCF file.  See the Xilinx 
  Synthesis and Verification Design Guide for more details on using this 
attribute if you are interested in learning more.



> 
> It would be better if the FF model should do rather more
> accurate modelling of metastability: the output should go
> to X, then after some settling time it should go to a 
> random choice of 0 or 1.  Once you have decided to do this,
> it's easy to make the model even more accurate:  use the
> precise time of the setup violation to determine how long
> the settling time should be, and to bias the random choice
> of 0/1.  However, if you do this, the FF model will probably
> become very inefficient and slow to simulate; so, once 
> again, you should apply this model only to the resynch
> FFs.


We have investigated this and while it is possible to use some 
statistical analysis (MTBF data) to attempt to predict the amount of 
settling time after a metastable event happens it will almost never be 
truly accurate (predicting this is still a bit more magic than science 
in my opinion) and the model will be far more complicated and slow.  We 
would not be able to use standard timing checks built into the simulator 
but instead craft our own.  These checks would need to not only look to 
see if a violation occurred but when it occurred in respect to the 
timing window and make predictions about how long the output should 
remain X and what the final value should settle to.  This would have to 
be done for every register in the simulation and I suspect it would slow 
down simulation by quite a few orders of magnitude and still we could 
not be confident that the output would be true-to-life (either in the 
prediction of settling time or the prediction of the end value that it 
settles to).  There are obvious liability issues to weigh in as well for 
that which is why we are taking the safe route and not planning to do 
this work any time soon.  My hope is that the ASYNC_REG attribute will 
suffice most people's needs for this.

> 
> There's another possible approach, which I have not tried.
> You could write some Verilog in your test fixture to
> sense the FF model's internal notifier register, and
> take control of the FF's output whenever the notifier
> toggles, using "assign" or "force".  In this way there
> would be no need to modify the simulation netlist, but
> you would need to know the exact structure of the models.
> And it assumes that the test fixture and the models are
> all written in Verilog - although that's probably a 
> fairly safe guess, for timing simulation.

Again, I suggest to use the existing mechanisms in the simulation 
libraries and netlists. Once you start taking a path like this or 
replacing models, all bets are off whether the simulation is still 
acting like it should.  But of course, to each their own and this is 
another tool in the tool box if you choose to use it but I would be very 
cautious if you do.

--  Brian

Article: 72608
Subject: Re: Xilinx Command Prompt
From: "kpatel -at- xilinx -dot- com" <"kpatel -at- xilinx -dot- com">
Date: Thu, 26 Aug 2004 09:50:13 -0600
Links: << >>  << T >>  << A >>
Ted,

The document you should be referencing to learn about command line tools 
and their options is the Development System Reference Guide for ISE 4.x 
found here:
http://toolbox.xilinx.com/docsan/xilinx4/pdf/docs/dev/dev.pdf

This document will cover the overview, syntax, inputs, outputs, and 
options for the command line tools you are using as well as some others 
you may need.

XST command line usage is covered in the XST User Guide for ISE 4.x 
found here:
http://toolbox.xilinx.com/docsan/xilinx4/pdf/docs/xst/xst.pdf

See Chapter 8 for more info on using XST command line mode.

I hope this helps.

Regards,
Kamal Patel
Xilinx Apps


Ted wrote:

>Hi,
>
>I'm trying to run the Xilinx toolset from the MS-DOS command prompt.
>Ultimatly I plan to do all of my VHDL design in Linux using WINE, but before
>I do that I want to get the commands working in MS-DOS.  The Xilinx software
>I'm using is ISE 4.2i.  For the first test I have created the following VHDL
>code (called source.vhd):
>
>/********************************************/
>library IEEE;
>use IEEE.STD_LOGIC_1164.ALL;
>use IEEE.STD_LOGIC_ARITH.ALL;
>use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
>entity source is
>    Port ( a : in std_logic;
>         b : out std_logic );
>end source;
>
>architecture Behavioral of source is
>begin
> b <= not a;
>end Behavioral;
>/********************************************/
>
>And I also have a constraints file, which is called source.ucf.  That file
>contains:
>
>/********************************************/
>NET "a" LOC = "p57";
>NET "b" LOC = "p82";
>/********************************************/
>
>To see what is involved, I first used the Project Navigator to implement the
>design in my FPGA.  I could then look at the log files to see what commands
>I needed to run and in what order.  The commands I ran are (the rsp files
>are the one's generated by Project Navigator):
>
>XST -ifn source.xst
>NGDBUILD -f __ngdbuild.rsp
>MAP -f _map.rsp
>PAR -f _par.rsp   (I changed this file)
>
>The file _par.rsp contained the following text:
>
>
>/********************************************/
>-ol 2
>-xe 0
>-t 1
>-c 0
>par_temp.ncd
>-w
>source.ncd
>source.pcf
>/********************************************/
>
>As I do not have a file called par_temp.ncd I deleted that line from the
>_par.rsp file (could that be the cause of my problem).
>
>My next step was to run bitgen to create the programming file, but when I
>ran it I got the following error:
>
>/********************************************/
>Running DRC.
>ERROR:DesignRules:542 - Netcheck: Design has unrouted nets - 1 unrouted net
>   warnings are not reported.
>ERROR:DesignRules:14 - Blockcheck: The component "a" has not been placed.
>ERROR:DesignRules:14 - Blockcheck: The component "b" has not been placed.
>WARNING:Bitgen:25 - DRC detected 3 errors and 1 warnings.
>/********************************************/
>
>It looks to me like my constraints file is not being used.  Is this the
>case?  If so, what have I done wrong and how can I tell the Xilinx toolset
>to use my constraints file?  If you need anymore info just say.
>
>
>Thanks for any help,
>
>
>  
>

Article: 72609
Subject: Re: Xilinx Command Prompt
From: Vincent <vincent.blablabla@blablabla.com>
Date: Thu, 26 Aug 2004 16:50:51 +0100
Links: << >>  << T >>  << A >>
Ted wrote:
> Hi,
> 
> I'm trying to run the Xilinx toolset from the MS-DOS command prompt.
> Ultimatly I plan to do all of my VHDL design in Linux using WINE, but before
> I do that I want to get the commands working in MS-DOS.  The Xilinx software
> I'm using is ISE 4.2i.  For the first test I have created the following VHDL
> code (called source.vhd):
> 
> /********************************************/
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> 
> entity source is
>     Port ( a : in std_logic;
>          b : out std_logic );
> end source;
> 
> architecture Behavioral of source is
> begin
>  b <= not a;
> end Behavioral;
> /********************************************/
> 
> And I also have a constraints file, which is called source.ucf.  That file
> contains:
> 
> /********************************************/
> NET "a" LOC = "p57";
> NET "b" LOC = "p82";
> /********************************************/
> 
> To see what is involved, I first used the Project Navigator to implement the
> design in my FPGA.  I could then look at the log files to see what commands
> I needed to run and in what order.  The commands I ran are (the rsp files
> are the one's generated by Project Navigator):
> 
> XST -ifn source.xst
> NGDBUILD -f __ngdbuild.rsp
> MAP -f _map.rsp
> PAR -f _par.rsp   (I changed this file)
> 
> The file _par.rsp contained the following text:
> 
> 
> /********************************************/
> -ol 2
> -xe 0
> -t 1
> -c 0
> par_temp.ncd
> -w
> source.ncd
> source.pcf
> /********************************************/
> 
> As I do not have a file called par_temp.ncd I deleted that line from the
> _par.rsp file (could that be the cause of my problem).
> 
> My next step was to run bitgen to create the programming file, but when I
> ran it I got the following error:
> 
> /********************************************/
> Running DRC.
> ERROR:DesignRules:542 - Netcheck: Design has unrouted nets - 1 unrouted net
>    warnings are not reported.
> ERROR:DesignRules:14 - Blockcheck: The component "a" has not been placed.
> ERROR:DesignRules:14 - Blockcheck: The component "b" has not been placed.
> WARNING:Bitgen:25 - DRC detected 3 errors and 1 warnings.
> /********************************************/
> 
> It looks to me like my constraints file is not being used.  Is this the
> case?  If so, what have I done wrong and how can I tell the Xilinx toolset
> to use my constraints file?  If you need anymore info just say.
> 
> 
> Thanks for any help,
> 
> 
Hi,

The command to include a ucf constraint file is ngdbuild -uc 
yourfile.ucf yourdesign.ngd
To know if your ucf file has been taken into account, look in the 
translate(ngdbuild) report (*.bld).

To know the tools and the options you can look in the software manual 
and then development system reference guide. For XST it is the software 
manual and then XST User Guide.
FYI the -f file.rsp option is to use a file to write your options in it. 
For example your could write your par line like: par -ol 2 -xe 0 -t 1 etc...
And you could put all the commands in a batch file (you might have done 
it already). however I recommend you to try each command line on its own 
first and the group them in batch files. For example translate and map 
in the same batch. You can also create different batch file for 
different implementation options.
Command line is very good to put files in different directories or give 
a different name to output file (for example the ouput of par (*.ncd) 
with a different name to avoid the confusion with the map output).

Vincent.

Article: 72610
Subject: Re: Xilinx Command Prompt
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Thu, 26 Aug 2004 10:04:58 -0600
Links: << >>  << T >>  << A >>


Ted,

    My suggestion is to rename your UCF file the same name as your top 
level source.  If your top-level source is source.vhd, then your UCF 
should be source.ucf.  Then I suggest using xflow to run the tools from 
command-line.  It is likely much easier than the path you are attempting 
to take now.  For instance to make the run it appears you are attempting 
below, the following command-line should take care of that:

xflow -p <put_partname_here> -synth vhdl_speed -implement balanced \ 
source.prj

Note: The above command-line is for 4.1/4.2i, it might be a little 
different for different releases. The prj file lists all of the VHDL 
designs in your project.  Take a look at the docs or the one in your GUI 
runs you have already done if you want to see the format.

You can customize your flow further if you wish and you can use the 
resulting bat file from the run if you prefer however I generally 
suggest removing the xflow.bat file and re-executing xflow each time as 
it will then better adjust to any future changes you would decide to 
make to how the design is implemented.

Generally, for those that want to run the Xilinx tools from 
command-line, i highly suggest using Xflow.  It has quite a few 
advantages over most other methods, especially when you are just 
starting out with learning the tools.

--  Brian





Ted wrote:

> Hi,
> 
> I'm trying to run the Xilinx toolset from the MS-DOS command prompt.
> Ultimatly I plan to do all of my VHDL design in Linux using WINE, but before
> I do that I want to get the commands working in MS-DOS.  The Xilinx software
> I'm using is ISE 4.2i.  For the first test I have created the following VHDL
> code (called source.vhd):
> 
> /********************************************/
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> 
> entity source is
>     Port ( a : in std_logic;
>          b : out std_logic );
> end source;
> 
> architecture Behavioral of source is
> begin
>  b <= not a;
> end Behavioral;
> /********************************************/
> 
> And I also have a constraints file, which is called source.ucf.  That file
> contains:
> 
> /********************************************/
> NET "a" LOC = "p57";
> NET "b" LOC = "p82";
> /********************************************/
> 
> To see what is involved, I first used the Project Navigator to implement the
> design in my FPGA.  I could then look at the log files to see what commands
> I needed to run and in what order.  The commands I ran are (the rsp files
> are the one's generated by Project Navigator):
> 
> XST -ifn source.xst
> NGDBUILD -f __ngdbuild.rsp
> MAP -f _map.rsp
> PAR -f _par.rsp   (I changed this file)
> 
> The file _par.rsp contained the following text:
> 
> 
> /********************************************/
> -ol 2
> -xe 0
> -t 1
> -c 0
> par_temp.ncd
> -w
> source.ncd
> source.pcf
> /********************************************/
> 
> As I do not have a file called par_temp.ncd I deleted that line from the
> _par.rsp file (could that be the cause of my problem).
> 
> My next step was to run bitgen to create the programming file, but when I
> ran it I got the following error:
> 
> /********************************************/
> Running DRC.
> ERROR:DesignRules:542 - Netcheck: Design has unrouted nets - 1 unrouted net
>    warnings are not reported.
> ERROR:DesignRules:14 - Blockcheck: The component "a" has not been placed.
> ERROR:DesignRules:14 - Blockcheck: The component "b" has not been placed.
> WARNING:Bitgen:25 - DRC detected 3 errors and 1 warnings.
> /********************************************/
> 
> It looks to me like my constraints file is not being used.  Is this the
> case?  If so, what have I done wrong and how can I tell the Xilinx toolset
> to use my constraints file?  If you need anymore info just say.
> 
> 
> Thanks for any help,
> 
> 

Article: 72611
Subject: Re: X propagation in Timing Simulation
From: jon@beniston.com (Jon Beniston)
Date: 26 Aug 2004 09:54:00 -0700
Links: << >>  << T >>  << A >>
muthusnv@yahoo.co.in (Muthu) wrote in message news:<4f8e807b.0408260230.2b5aaf74@posting.google.com>...
> Hi,
> 
> In a timing simulation, Setup / Hold violation of Flip-Flop will
> result in value of 'x' at the output. Is that Right?

Usually.

> If so, how double synchronisation circuits work in timing simulation ?
> Won't it propagate x. ?

See part 12.0 in this very good paper:

http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk_rev1_1.pdf

Cheers,
JonB

Article: 72612
Subject: Re: JTAG software
From: jon@beniston.com (Jon Beniston)
Date: 26 Aug 2004 09:55:23 -0700
Links: << >>  << T >>  << A >>
fatboyslim123@softhome.net (FatBoySlim) wrote in message news:<4182a556.0408260015.5cac5b85@posting.google.com>...
> From where can i get a JTAG software .
> I have a FPGA chip and configuration bit file.
> So how shall i load the bits to FPGA chip

Which FPGA? If it's Xilinx you should look for the iMPACT program
which is part of WebPack, which is freely available on their site.

Cheers,
JonB

Article: 72613
Subject: Re: JTAG software
From: raonpc@gmail.com (pablo aimar)
Date: 26 Aug 2004 10:36:13 -0700
Links: << >>  << T >>  << A >>
####
> From where can i get a JTAG software .
> I have a FPGA chip and configuration bit file.
> So how shall i load the bits to FPGA chip

# Based on the fpga(Alter/xilinx/...) that you are using you
  can download free web editions from their respective web sites.

# you may also need respective programming cables.

Regards
rao

Article: 72614
Subject: PP1000SetupDMAChannel( ) function in celoxica RC1000
From: chandrika.anad@gmail.com (cka)
Date: 26 Aug 2004 11:40:34 -0700
Links: << >>  << T >>  << A >>
hi,
i am new to FPGA's. i am using celoxica RC1000 to implement a digital
beamformer. i have a text file with 12-bit binary data which i use as
the input to my beamformer.
my understanding is tht we have to read the text file into an array
and then specify the array name in the PP1000SetupDMAChannel()
function.
i am unaware of a method to read the binary numbers in the text file
into an array in c. i am not sure if my line of thought to write data
into the memory of the FPGA is correct.can somebody guide me?
thank you very much.
c'ka.

Article: 72615
Subject: problem with DDR
From: vinodece@yahoo.co.in (vinod)
Date: 26 Aug 2004 11:50:13 -0700
Links: << >>  << T >>  << A >>
i am vinod..i got problem with ddr for virtex2 fpga. i have written
code and did functional simulation everything is correct but after
post translate simulation i am not getting same result. here is my
code and testbench

code: 
library ieee; 
use ieee.std_logic_1164.all; 
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;

entity input_ddr is 
Port ( d : in std_logic; 
reset : in std_logic;
clk : in std_logic; 
dataoutx : out std_logic;
dataouty : out std_logic
 ); 
end input_ddr; 

architecture input_ddr_arch of input_ddr is 
 

signal q1, q2 : std_logic; 
 
 

begin 
 
 
 

process (clk,d,reset) 
begin 

if reset = '1' then
  q1 <= '0';
  dataoutx <= '0';

elsif  rising_edge(clk) then 
q1 <= d; 
dataoutx <= q1;
end if; 
end process; 

process (clk,d,reset)
begin 
if reset = '1' then
 q2 <= '0';
 dataouty <= '0';
elsif  falling_edge(clk)  then 
q2 <= d; 
dataouty <= q2;
end if; 
end process; 

 

end input_ddr_arch; 

testbench....
library ieee; 
use ieee.std_logic_1164.all;  library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;

entity tbddr is
end entity tbddr;

architecture test2 of tbddr is
component  input_ddr is 
Port ( d : in std_logic; 
reset : in std_logic;
clk : in std_logic; 
dataoutx : out std_logic;
dataouty : out std_logic
 ); 
end component ; 
 

component FDDRRSE is
port (

Q : out STD_ULOGIC;
C0 : IN STD_ULOGIC;
C1 : IN STD_ULOGIC;
CE  :IN STD_ULOGIC;
D0 : IN STD_ULOGIC;
D1 : IN STD_ULOGIC;
R  :IN STD_ULOGIC ;
S : IN STD_ULOGIC
);
end component;

 
 
signal risdatax,faldatax : std_ulogic;
signal dataoutx,dataouty : std_logic;
signal count : natural range 0 to 15;
--signal cnt : natural range 0 to 40;
signal ind : std_logic;
signal S,R,cE :std_logic;
 
signal data : std_ulogic_vector(15 downto 0):="1101000111010101";
signal data1 : std_ulogic_vector(15 downto 0):= "1001011100011100";
--signal data2: std_ulogic_vector(15 downto 0):= "0010100111001011";
signal clk,invclk,  reset :std_logic;
signal clk2 ,d : std_logic;
begin

--clk2 <= not  clk;


uut1: input_ddr
port map (
 d   => d,
 clk  => clk,
reset => reset,
dataoutx => dataoutx,
dataouty => dataouty
  
 
);


FDDRRSEx : FDDRRSE
port map (

Q => d,
C0 => clk,
c1 => invclk,
CE => ce,

d0  => risdatax,
d1 =>  faldatax,
r => '0',
s => '0'
);

 
 
clock1 : process
begin
 clk <= '1';
 invclk <= '0';
wait for 10 ns;

clk <= '0';
invclk <= '1';
wait for 10 ns;
end process;

stimuli : process 
begin 
wait for 20 ns;
reset <= '1';
 
wait for 40 ns;
reset <= '0';

 
 
wait;
end process stimuli;

process(clk,reset,ind)
begin 
  if reset  = '1' then
    count <= 0;
	 ce <= '0';
	 risdatax <= '0';
	 faldatax <= '0';
elsif clk'event and clk = '1' then
  
 ce <= '1';
  risdatax <= data(count);
  faldatax <= data1(count);
  if count < 15 then
  count <= count+1;
   elsif count = 15 then
	  count <= 0;
  end if;
  end if;
  
 end process;
end test2;



i have used FFDDRSE primitive in testbench for generating double data
rate.

i will be waiting for reply...

thanks in advance
bye

Article: 72616
Subject: Re: 6.1 vs. 6.2
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Thu, 26 Aug 2004 13:58:31 -0600
Links: << >>  << T >>  << A >>


Mike Treseler wrote:

<snip>
> 
> Simulation is an alternative to logic analysis.
> For synchronous designs, a functional sim and
> Xilinx static timing is all the chipscope you need.
> 


I wanted to say a few words to this statement.  In general I agree with 
the idea that careful, well thought out synchronous designs with 
careful, well thought out static timing analysis covers most bases for 
ensuring a functional end design however there are a few situations that 
some, perhaps many, often over look that can be easily caught in a 
timing simulation and can not be easily detected with any of the above 
methods including Chipscope.  One of those such situations is BlockRAM 
collisions.  If you are using a RAM in Dual-Port mode, it is illegal to 
access the same address on both ports of the RAM within a timing window 
when one or both ports are doing a write.  The obvious situation most 
think of is the write-write situation where you can not write different 
data to the same address at the same time and most safe guard against 
that however it seems the situation of a read-write collision can be for 
more easily over looked.  If you are reading from one port of a RAM and 
at the approximately same time writing to the other at the same address, 
there is no tell whether the read data will be the old data, the new 
data or something in-between.  If that read data is used anywhere else 
in the design it should be considered corrupted yet static timing 
analysis or on-chip analysis will not show or tell you of this problem. 
  Timing simulation is the only way to properly detect this and this can 
occur in a completely synchronous design with only a single clock.

Timing simulation also ensures your design is properly constrained and 
nothing is missed during static timing analysis (is that path really a 
multi-cycle path?  Can you safely ignore timing on this path?  Did you 
miss anything?).  As you instantiate more complex components like DCMs, 
BlockRAMs, etc., that all of the attributes came across the software 
properly and if you are crossing clock domains that your design will 
likely operate as you would expect.  Are you certain the synthesis tool 
interpreted your code they way you think it did?  Were there delays in 
the code, missed items in the sensitivity list, misconnnected components 
or other things in the code to make it behaviorally simulate different 
than it was implemented by synthesis?

If you are prepared with your testbench to do timing simulations, in 
general not too much time or overhead needs to be spent at this step and 
at minimum it will be another check off the list of ensuring the design 
is properly verified and all things have been considered.  Many times it 
will save far more time than is spent here especially if you do find an 
issue such as above that can not be easily identified by other 
verification methods. Also of course with careful design, most all of 
these situations can be avoided but even the most careful designer can 
make mistakes.

Just my 2 cents on the subject,

--  Brian


Article: 72617
Subject: Re: Xilinx Command Prompt
From: rajarsheeb@yahoo.com (raj)
Date: 26 Aug 2004 12:59:40 -0700
Links: << >>  << T >>  << A >>
Hi Ted,
> 
> To see what is involved, I first used the Project Navigator to implement the
> design in my FPGA.  I could then look at the log files to see what commands
> I needed to run and in what order.  The commands I ran are (the rsp files
> are the one's generated by Project Navigator):
> 
> XST -ifn source.xst
> NGDBUILD -f __ngdbuild.rsp
You have to give your UCF as input in NGDBUILD.
Check this file whether it has associated the .ucf file or not.
You can try this in command line as:

ngdbuild -intstyle ise -dd . -uc MYDESIGN.ucf -p YOUR_DEVICE  XXX.ngc XXX.ngd

(-dd switch is for destination directory,-uc for ucf, -p for part name )

This will create a pcf file which the mapping and pnr takes as input. 

Hope this helps..

--raj


> MAP -f _map.rsp
> PAR -f _par.rsp   (I changed this file)
> 
> The file _par.rsp contained the following text:
> 
> 
> /********************************************/
> -ol 2
> -xe 0
> -t 1
> -c 0
> par_temp.ncd
> -w
> source.ncd
> source.pcf
> /********************************************/
> 
> As I do not have a file called par_temp.ncd I deleted that line from the
> _par.rsp file (could that be the cause of my problem).
> 
> My next step was to run bitgen to create the programming file, but when I
> ran it I got the following error:
> 
> /********************************************/
> Running DRC.
> ERROR:DesignRules:542 - Netcheck: Design has unrouted nets - 1 unrouted net
>    warnings are not reported.
> ERROR:DesignRules:14 - Blockcheck: The component "a" has not been placed.
> ERROR:DesignRules:14 - Blockcheck: The component "b" has not been placed.
> WARNING:Bitgen:25 - DRC detected 3 errors and 1 warnings.
> /********************************************/
> 
> It looks to me like my constraints file is not being used.  Is this the
> case?  If so, what have I done wrong and how can I tell the Xilinx toolset
> to use my constraints file?  If you need anymore info just say.
> 
> 
> Thanks for any help,

Article: 72618
Subject: Re: Altera MAX II
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 27 Aug 2004 07:59:46 +1200
Links: << >>  << T >>  << A >>
Luiz Carlos wrote:
>>PS Also missing from this spin, is the fact that the cheapest 
>>previous-generation MAX devices, are actually cheaper than the
>>cheapest MAX II devices.
>>  ie the price per resource unit has declined, but the
>>minimum unit-cost step has actually increased, because they
>>pruned the two smallest offerings.
> 
> 
> Jim,
> 
> Do you mean the 32 and 64 macrocells MAX1 devices are dead?

  Not yet, but they did not move forward a generation.
That means if you are starting a new design, you should look
carefully at vendors whose parts have moved forward recently.

> And the 128 macrocells MAX1 is cheaper than the "198 macrocell" MAX2?

  The asymptope price mentioned for MAX II is $1.50, which is quite
a lot higher than the cheapest MAX1.
  Thus if you have a smallish amount of logic, and want some of the MAX 
II features, or even a reduction in power, but no increase in price, 
then you are out of luck.
  Altera has left that market sector behind, but MAX II WILL have a 
significant impact on the biggest CPLDs.

  Fortunately in the 32/64 MCell area, there are still Xilinx, Lattice,
and Atmel, all with low power devices.

  My point was really that when marketing trumpet 'half the price'
that's not always the whole story :)

-jg


Article: 72619
Subject: Re: 6.1 vs. 6.2
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 26 Aug 2004 13:40:36 -0700
Links: << >>  << T >>  << A >>
Brian,

Great post.  We just had the same conclusions at a meeting here 
yesterday on what constitutes necessary and sufficient checks on designs.

Austin

Brian Philofsky wrote:
> 
> 
> Mike Treseler wrote:
> 
> <snip>
> 
>>
>> Simulation is an alternative to logic analysis.
>> For synchronous designs, a functional sim and
>> Xilinx static timing is all the chipscope you need.
>>
> 
> 
> I wanted to say a few words to this statement.  In general I agree with 
> the idea that careful, well thought out synchronous designs with 
> careful, well thought out static timing analysis covers most bases for 
> ensuring a functional end design however there are a few situations that 
> some, perhaps many, often over look that can be easily caught in a 
> timing simulation and can not be easily detected with any of the above 
> methods including Chipscope.  One of those such situations is BlockRAM 
> collisions.  If you are using a RAM in Dual-Port mode, it is illegal to 
> access the same address on both ports of the RAM within a timing window 
> when one or both ports are doing a write.  The obvious situation most 
> think of is the write-write situation where you can not write different 
> data to the same address at the same time and most safe guard against 
> that however it seems the situation of a read-write collision can be for 
> more easily over looked.  If you are reading from one port of a RAM and 
> at the approximately same time writing to the other at the same address, 
> there is no tell whether the read data will be the old data, the new 
> data or something in-between.  If that read data is used anywhere else 
> in the design it should be considered corrupted yet static timing 
> analysis or on-chip analysis will not show or tell you of this problem. 
>  Timing simulation is the only way to properly detect this and this can 
> occur in a completely synchronous design with only a single clock.
> 
> Timing simulation also ensures your design is properly constrained and 
> nothing is missed during static timing analysis (is that path really a 
> multi-cycle path?  Can you safely ignore timing on this path?  Did you 
> miss anything?).  As you instantiate more complex components like DCMs, 
> BlockRAMs, etc., that all of the attributes came across the software 
> properly and if you are crossing clock domains that your design will 
> likely operate as you would expect.  Are you certain the synthesis tool 
> interpreted your code they way you think it did?  Were there delays in 
> the code, missed items in the sensitivity list, misconnnected components 
> or other things in the code to make it behaviorally simulate different 
> than it was implemented by synthesis?
> 
> If you are prepared with your testbench to do timing simulations, in 
> general not too much time or overhead needs to be spent at this step and 
> at minimum it will be another check off the list of ensuring the design 
> is properly verified and all things have been considered.  Many times it 
> will save far more time than is spent here especially if you do find an 
> issue such as above that can not be easily identified by other 
> verification methods. Also of course with careful design, most all of 
> these situations can be avoided but even the most careful designer can 
> make mistakes.
> 
> Just my 2 cents on the subject,
> 
> --  Brian
> 

Article: 72620
Subject: Re: problem with DDR
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Thu, 26 Aug 2004 15:30:51 -0600
Links: << >>  << T >>  << A >>

Vinod,

I would guess that the reason you are seeing a functional difference 
would be due to the fact that you are not waiting until the global 
set/reset signal to complete.  For all Xilinx gate-level simulations, a 
global set/reset pulse is generated for the first 100 ns of the design 
to initialize all of the registers and simulate the effect for the GSR 
signal in simulation.  For the first 100 ns of the design, the registers 
will be in reset and will not change value.  If you hold off you 
stimulus for the first 100 ns of simulation (keep your clock running and 
initialize the inputs but just don't wiggle them yet), you will likely 
see more correlation between your behavioral and post-translate simulation.

Also, if you are desiring to have the DDR register pulled into the I/O 
and use the dedicated resource, you should be instantiating the IFDDRRSE 
in the design.  The code you are creating will use two separate 
registers but not the dedicated DDR registers in the I/O.


--  Brian


vinod wrote:

> i am vinod..i got problem with ddr for virtex2 fpga. i have written
> code and did functional simulation everything is correct but after
> post translate simulation i am not getting same result. here is my
> code and testbench
> 
> code: 
> library ieee; 
> use ieee.std_logic_1164.all; 
> library UNISIM;
> use UNISIM.VCOMPONENTS.ALL;
> 
> entity input_ddr is 
> Port ( d : in std_logic; 
> reset : in std_logic;
> clk : in std_logic; 
> dataoutx : out std_logic;
> dataouty : out std_logic
>  ); 
> end input_ddr; 
> 
> architecture input_ddr_arch of input_ddr is 
>  
> 
> signal q1, q2 : std_logic; 
>  
>  
> 
> begin 
>  
>  
>  
> 
> process (clk,d,reset) 
> begin 
> 
> if reset = '1' then
>   q1 <= '0';
>   dataoutx <= '0';
> 
> elsif  rising_edge(clk) then 
> q1 <= d; 
> dataoutx <= q1;
> end if; 
> end process; 
> 
> process (clk,d,reset)
> begin 
> if reset = '1' then
>  q2 <= '0';
>  dataouty <= '0';
> elsif  falling_edge(clk)  then 
> q2 <= d; 
> dataouty <= q2;
> end if; 
> end process; 
> 
>  
> 
> end input_ddr_arch; 
> 
> testbench....
> library ieee; 
> use ieee.std_logic_1164.all;  library ieee;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> library UNISIM;
> use UNISIM.VCOMPONENTS.ALL;
> 
> entity tbddr is
> end entity tbddr;
> 
> architecture test2 of tbddr is
> component  input_ddr is 
> Port ( d : in std_logic; 
> reset : in std_logic;
> clk : in std_logic; 
> dataoutx : out std_logic;
> dataouty : out std_logic
>  ); 
> end component ; 
>  
> 
> component FDDRRSE is
> port (
> 
> Q : out STD_ULOGIC;
> C0 : IN STD_ULOGIC;
> C1 : IN STD_ULOGIC;
> CE  :IN STD_ULOGIC;
> D0 : IN STD_ULOGIC;
> D1 : IN STD_ULOGIC;
> R  :IN STD_ULOGIC ;
> S : IN STD_ULOGIC
> );
> end component;
> 
>  
>  
> signal risdatax,faldatax : std_ulogic;
> signal dataoutx,dataouty : std_logic;
> signal count : natural range 0 to 15;
> --signal cnt : natural range 0 to 40;
> signal ind : std_logic;
> signal S,R,cE :std_logic;
>  
> signal data : std_ulogic_vector(15 downto 0):="1101000111010101";
> signal data1 : std_ulogic_vector(15 downto 0):= "1001011100011100";
> --signal data2: std_ulogic_vector(15 downto 0):= "0010100111001011";
> signal clk,invclk,  reset :std_logic;
> signal clk2 ,d : std_logic;
> begin
> 
> --clk2 <= not  clk;
> 
> 
> uut1: input_ddr
> port map (
>  d   => d,
>  clk  => clk,
> reset => reset,
> dataoutx => dataoutx,
> dataouty => dataouty
>   
>  
> );
> 
> 
> FDDRRSEx : FDDRRSE
> port map (
> 
> Q => d,
> C0 => clk,
> c1 => invclk,
> CE => ce,
> 
> d0  => risdatax,
> d1 =>  faldatax,
> r => '0',
> s => '0'
> );
> 
>  
>  
> clock1 : process
> begin
>  clk <= '1';
>  invclk <= '0';
> wait for 10 ns;
> 
> clk <= '0';
> invclk <= '1';
> wait for 10 ns;
> end process;
> 
> stimuli : process 
> begin 
> wait for 20 ns;
> reset <= '1';
>  
> wait for 40 ns;
> reset <= '0';
> 
>  
>  
> wait;
> end process stimuli;
> 
> process(clk,reset,ind)
> begin 
>   if reset  = '1' then
>     count <= 0;
> 	 ce <= '0';
> 	 risdatax <= '0';
> 	 faldatax <= '0';
> elsif clk'event and clk = '1' then
>   
>  ce <= '1';
>   risdatax <= data(count);
>   faldatax <= data1(count);
>   if count < 15 then
>   count <= count+1;
>    elsif count = 15 then
> 	  count <= 0;
>   end if;
>   end if;
>   
>  end process;
> end test2;
> 
> 
> 
> i have used FFDDRSE primitive in testbench for generating double data
> rate.
> 
> i will be waiting for reply...
> 
> thanks in advance
> bye

Article: 72621
Subject: Re: DDR SDRAM
From: Marcus Harnisch <marcus.harnisch@gmx.net>
Date: Thu, 26 Aug 2004 23:44:23 +0200
Links: << >>  << T >>  << A >>
Hi Andre,

Don't get me wrong, but if you are trying to decypher the waves at the
SDRAM interface it would help if you'd know about some of the basics
of DDR SDRAMs. The "usual suspects" (Micron, Samsung, etc.) provide
good datasheets for download. JEDEC79x (x >= C) might be a little
dry but is certainly the most comprehensive source of information in
that respect.

Good luck,
Marcus

Article: 72622
Subject: Re: 6.1 vs. 6.2
From: Simon <news@gornall.net>
Date: Thu, 26 Aug 2004 21:46:48 GMT
Links: << >>  << T >>  << A >>
Brian Philofsky wrote:
> 
> 
> Mike Treseler wrote:
> 
> <snip>
> 
>>
>> Simulation is an alternative to logic analysis.
>> For synchronous designs, a functional sim and
>> Xilinx static timing is all the chipscope you need.
>>
> 
> 
> I wanted to say a few words to this statement.  In general I agree with 
> the idea that careful, well thought out synchronous designs with 
> careful, well thought out static timing analysis covers most bases for 
> ensuring a functional end design however there are a few situations that 
> some, perhaps many, often over look that can be easily caught in a 
> timing simulation and can not be easily detected with any of the above 
> methods including Chipscope.  One of those such situations is BlockRAM 
> collisions.  If you are using a RAM in Dual-Port mode, it is illegal to 
> access the same address on both ports of the RAM within a timing window 
> when one or both ports are doing a write.  The obvious situation most 
> think of is the write-write situation where you can not write different 
> data to the same address at the same time and most safe guard against 
> that however it seems the situation of a read-write collision can be for 
> more easily over looked.  If you are reading from one port of a RAM and 
> at the approximately same time writing to the other at the same address, 
> there is no tell whether the read data will be the old data, the new 
> data or something in-between.  If that read data is used anywhere else 
> in the design it should be considered corrupted yet static timing 
> analysis or on-chip analysis will not show or tell you of this problem. 
>  Timing simulation is the only way to properly detect this and this can 
> occur in a completely synchronous design with only a single clock.

Actually in the newer BlockRAM implementations, you can choose the 
behaviour (at least you can on the Spartan-3, whose datasheets I've been 
poring over recently :-)

There's:

   o READ_FIRST, which will always report the value of the data
     in RAM before the write was committed

   o WRITE_FIRST, which will provide the unpredictable behaviour
     you mention (and it's the default, to provide backwards
     compatibility)

   o NO_CHANGE, which seems to disconnect the output RAM so the
     output value remains unchanged.

I doubt anything would help you if you simultaneously write into the 
same address on both ports, though :-)

Simon.

Article: 72623
Subject: Re: EPM7064LC44-7 - Not there in Quartus II...
From: "Antti Lukats" <antti@case2000.com>
Date: Thu, 26 Aug 2004 14:48:03 -0700
Links: << >>  << T >>  << A >>
"Drew" <dhruvish@gmail.com> wrote in message
news:ad2011c0.0408260441.39841b@posting.google.com...
> Hello guys,
>
> I am trying to Assign the Max Family EPLD - EPM7064 LC44-7 and run my
> compilation. But in the Assign Device I find EPM7064 SLC44-7. There
> are some significant differences between LC and SLC in terms of Max
> allowable freq, LCELL delay etc. Please let me know if anybody can
> find it in the Assign Device section.

its not there! all the devices with no JTAG ISP are dropped from Quartus,
you need to use MAXPLUS !
but you need a special programmer to program those old PLDs anyway, you can
not program them with byteblaster !

Antti



Article: 72624
Subject: Re: Xilinx Command Prompt
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Thu, 26 Aug 2004 17:48:16 -0400
Links: << >>  << T >>  << A >>
On Thu, 26 Aug 2004 15:45:05 +0100, Ted wrote:

> Hi,
> 
> I'm trying to run the Xilinx toolset from the MS-DOS command prompt.
> Ultimatly I plan to do all of my VHDL design in Linux using WINE, but before
> I do that I want to get the commands working in MS-DOS.  The Xilinx software
> I'm using is ISE 4.2i.  For the first test I have created the following VHDL
> code (called source.vhd):
> 
> /********************************************/
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> 
> entity source is
>     Port ( a : in std_logic;
>          b : out std_logic );
> end source;
> 
> architecture Behavioral of source is
> begin
>  b <= not a;
> end Behavioral;
> /********************************************/
> 
> And I also have a constraints file, which is called source.ucf.  That file
> contains:
> 
> /********************************************/
> NET "a" LOC = "p57";
> NET "b" LOC = "p82";
> /********************************************/
> 
> To see what is involved, I first used the Project Navigator to implement the
> design in my FPGA.  I could then look at the log files to see what commands
> I needed to run and in what order.  The commands I ran are (the rsp files
> are the one's generated by Project Navigator):
> 
> XST -ifn source.xst
> NGDBUILD -f __ngdbuild.rsp
> MAP -f _map.rsp
> PAR -f _par.rsp   (I changed this file)
> 
> The file _par.rsp contained the following text:
> 
> 
> /********************************************/
> -ol 2
> -xe 0
> -t 1
> -c 0
> par_temp.ncd
> -w
> source.ncd
> source.pcf
> /********************************************/
> 
> As I do not have a file called par_temp.ncd I deleted that line from the
> _par.rsp file (could that be the cause of my problem).
> 
> My next step was to run bitgen to create the programming file, but when I
> ran it I got the following error:
> 
> /********************************************/
> Running DRC.
> ERROR:DesignRules:542 - Netcheck: Design has unrouted nets - 1 unrouted net
>    warnings are not reported.
> ERROR:DesignRules:14 - Blockcheck: The component "a" has not been placed.
> ERROR:DesignRules:14 - Blockcheck: The component "b" has not been placed.
> WARNING:Bitgen:25 - DRC detected 3 errors and 1 warnings.
> /********************************************/
> 
> It looks to me like my constraints file is not being used.  Is this the
> case?  If so, what have I done wrong and how can I tell the Xilinx toolset
> to use my constraints file?  If you need anymore info just say.
> 
> 
> Thanks for any help,

Why are you using 4.2? 6.2 is Linux native. Also there is no XST in 4.2,
you need 6.x for that (the 5.x version didn't work very well, the current
version works fine). If you are planning on working in a Linux
environment eventually then install cygwin on your Windows machine. That
will allow you to use the same shells as Linux. I've included a complete
set of csh scripts for running the Xilinx tools in HDLmaker,

http://www.polybus.com/hdlmaker/users_guide/

Look under hdlmaker_lib/csh, you'll find a number of useful csh scripts. 

If you use HDLmaker to build your hierarchy it will generate all of the
constraint files that you need including a script for XST and the UCF
file. HDLmaker works best in Verilog, the VHDL support has been
deprecated. It's been 6 or 7 years since any of my clients have wanted
VHDL, every company that I deal with uses Verilog. As a result I haven't
been maintaining the VHDL generators in HDLmaker, all of the work has gone
into Verilog. HDLmaker runs fine under Cygwin and of course it works on
all *nixs.




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