Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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 DrewArticle: 72601
"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
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 TreselerArticle: 72603
"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_comArticle: 72604
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 FAXArticle: 72605
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: 72606On 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
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. -- BrianArticle: 72608
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
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
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: 72611muthusnv@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, JonBArticle: 72612
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, JonBArticle: 72613
#### > 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 raoArticle: 72614
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
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: 72616Mike 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, -- BrianArticle: 72617
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
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 :) -jgArticle: 72619
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
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 > byeArticle: 72621
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, MarcusArticle: 72622
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"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 ! AnttiArticle: 72624
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:
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