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
Weng, This is correct for your "State_A" example: > -- assert onehot0 (E0, E1, E2) ; -- Jim wrote > -- assert onehot0 (E3, E4, E5) ; This is correct for your "OutBus" example. > assert onehot0 (E0, E1, E2, E3, E4, E5) ; -- Weng adds this line Note I did not write an assertion for your OutBus example as although it would be nice to have for simulation, it is not needed at all to get the hardware you desire. > The above two example show that with mixed 'elsif' and 'orif' language > branch statement structure, HDL will provide more powerful and concise > way to deal with mutually exclusiveness. Not sure I am comfortable with mixing elsif with orif without other syntax to reinforce the intent. I am concerned that this would increase the design risk. Are you certain your testbench is good enough? Without more analysis, I would rather write a separate specification for mutual exclusion (via the assertion) as this clearly states intent. > VHDL beginner would need to go a long way to write the code > type Jim had written. Why is a beginner too inept to write an assert statement especially for your trival code above? You mention that the big draw back to using complex conditions is that you would have to create intermediate signals. Why is that bad? Again, I need to see compelling code cases. Cheers, JimArticle: 123601
Kolja, > result <= > (input1 and (result'range => E1)) or > (input2 and (result'range => E2)) or > (input3 and (result'range => E3)) ; This is another of the correct, but annoying pieces of code that some synthesis tools (Synopsys) did not implement the last I checked. Anyone know if they fixed this? This is the primary reason for the new overloading on logic operations (AND, OR, ...) that allow mixing a scalar (std_ulogic) with a vector (std_logic_vector). As a result, with the new revision or old revision with supplemental overloading one can write: result <= (input1 and E1) or (input2 and E2) or (input3 and E3); Cheers, JimArticle: 123602
hi sean, > Hmm, the bin should be loaded completely... the only thing I can think > of why it would not be is that the configuration logic requires some > clock cycles after the configuration data to empty it's internal > pipeline. Can you explain how to do this. What modification should I do in the code. Thanking you, ajith.Article: 123603
On Aug 30, 10:35 am, EEngineer <mari...@gmail.com> wrote: > On Aug 30, 11:12 am, Gabor <ga...@alacron.com> wrote: > > > > > On Aug 30, 10:14 am, EEngineer <mari...@gmail.com> wrote: > > > > On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote: > > > > > On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > > > > > > "EEngineer" <mari...@gmail.com> wrote in message > > > > > >news:1188426999.764557.233750@k79g2000hse.googlegroups.com... > > > > > > > there are also UCF lines: > > > > > > > NET ctrl_data<*> SLEW = FAST; > > > > > > NET ctrl_data<*> DRIVE = 2; > > > > > > NET ctrl_data<*> IOSTANDARD = LVCMOS33; > > > > > > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not > > > > > something that will make your outputs happen coincident with your clock, > > > > > it's a specification that will simply fail in the place & route and timing > > > > > analyzer. Take a look. The fastest your outputs will go depend on how fast > > > > > an IOB register can deliver its output relative to your global clock. These > > > > > numbers are documented and easy to prototype. > > > > > > Second, the 2 mA drive level will give you a slower rise/fall. The skew in > > > > > your output signal time can - depending on your load - be a noticeable time > > > > > difference. > > > > > > Third, the logic analyzer is an asynchronous device which will usually > > > > > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns > > > > > difference not explained by the test equipment. > > > > > > Please find the online documentation (or a Xilinx class) that describes what > > > > > you can and cannot do with constraints. This fundamental information > > > > > usually is only understood after an engineer can't understand why their > > > > > design isn't working. Learn it. > > > > > If you need your outputs to have very low skew, your only hope > > > > is to place all of the output flip-flops in the IOB's (IOB=TRUE > > > > attribute on the flip-flop or net). You can also globally place > > > > registers in IOB's using the synthesis and map properties. If > > > > your outputs are generated by fabric flip-flops it is very hard > > > > to get your skew below 2.5 nS > > > > > By the way, why do you need such low skew on these lines? Is the > > > > driven device asynchronous with respect to your clock? > > > > > Regards, > > > > Gabor > > > > I need those signals to control the analog CMOS circuit that has a > > > requirement for some signals not to overlap - this happens when the > > > output from the FPGA is not synchronous enough. > > > These signals will never be "synchronous enough" to guarantee zero > > overlap when changing on the same clock cycle. Use a faster clock > > if you need to, but certainly add a clock cycle between assertion > > of signals that must not overlap. > > Yes, I was thinking of using 16 times faster clock to add one clock > cycle in between, but I have checked signals with the 500MHz scope > (10Mohm, 9.5pF probes) and it looks like that digital analyser is > giving misleading waveforms - there is almost no delay between these > two signals (less then 1ns). The rise time is same for both signals, > and this can be improved by increasing the drive in UCF file from the > minimum 2mA, I don't know the load yet. You might want to learn how a logic analyzer works. It sounds like your analyzer has a 400 MHz sample clock because of your noted 2.5 ns uncertainty. This sample clock is of course asynchronous to your circuit. So even if your FPGA's outputs are skewed less than 1 ns (as you point out), that window might include the logic analyzer's sample point, and as such signals that are in reality only 500 ps apart appear on the analyzer to be 2.5 ns apart. So you should ensure that all of your signals are registered by a low- skew clock in the IOBs and ensure that your PCB routing has equal length lines from the FPGA to the load. This should result in quite good skew matching. Also make sure the output s set to FAST, and increase the drive strength. Read your timing analyzer's report for I/ O clock-to-out times. And if the requirement is to ensure that two outputs are never enabled simultaneously, then do as Gabor says and insert a one-clock dead time between the deassertion of one output and the assertion of the other. -aArticle: 123604
"PeteS" <axkz70@dsl.pipex.com> wrote in message news:H-ydnSZMEttzlkrbnZ2dnUVZ8vidnZ2d@pipex.net... <snip> > > I have a number of pretty pics I made to illustrate the issue. I'll put > 'em on a.b.s.e tomorrow sometime. > > As an aside, at high speeds (which I define as having a track longer than > 1/4 rising/falling edge, YMMVG), there is no such thing as 'ground'. The > ground plane is a signal layer insulated by copper ;) > [Although it helps to keep large power currents away from the high speed > return paths]. > > Cheers > > PeteS Since without a ground one has a dipole antenna, could you qualify what you mean? The impedance of the plane is measured in units of picoHenry per square so it's not a solid ground, certainly, but without a ground we'd be in a world of hurt at these high frequencies.Article: 123605
eli.billauer@gmail.com wrote:
> But please, try this out.
I will use quartus only because it makes nicer graphics.
ISE would give me equivalent results:
Here's the code I used
http://home.comcast.net/~mike_treseler/multicycle.v
The RTL viewer sees the code like this:
http://home.comcast.net/~mike_treseler/multicycle.pdf
Quartus synthesis in a default Stratix device says:
; Total registers ; 19 ;
; Total logic cells in carry chains ; 15 ;
Static timing with default constraints says:
; Type ; Actual Time
+----------------------+---------------------------------
Clock Setup: 'clk' ; 249.81 MHz ( period = 4.003 ns )
Here's how synthesis did the fit:
http://home.comcast.net/~mike_treseler/multicycle_fit.pdf
I see no reason to tinker with timing constraints in this case.
-- Mike Treseler
Article: 123606
Weng,
I'll say this: I admire your tenacity.
The coding Jim provided was to illustrate a way, with today's standard
(not including PSL), to code your orif example such that the synthesis
tool would give the equivalent implementation.
Since you seem to be in favor of powerful and concise ways to
implement this, an even better way to code this function would be to
use arrays, particularly with more than just 6 choices involved:
process (reset, clk) is
variable: temp : std_logic_vector(outbus'range);
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
temp := (others => '0');
for i in e'range loop
temp := temp or (e(i) and data(i));
end loop;
if unsigned(e) /= 0 then
outbus <= temp;
end if;
end if;
end process;
Now, if we are allowed to extend the standard (not the language), with
the use of a synthesis-aware assertion and zero_one_hot() function,
this can be greatly simplified, while also making it more functionally
clear:
process (reset, clk) is
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
for i in e'range loop
if e(i) = '1' then
outbus <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(e);
end if;
end process;
However, a loop of if/then statements is not compatible with your
proposed orif keyword.
Therefore, we have a more powerful and concise example of coding this
function with zero_one_hot() than is possible with a new keyword
'orif'.
So, zero_one_hot() can do everything 'orif' can do and more, while
doing so more concisely, and not requiring a language syntax change.
Why do we need 'orif'?
Andy
Article: 123607On Aug 30, 11:57 am, Pasacco <pasa...@gmail.com> wrote: > Let me ask other question. > > FPGA device consists of > Huge SRAM cells (around 10 Mbits, xc2vp30-ff896) + memory controller + > hard cores (such as PPC, multiplier) > > If we neglect hard cores, > > I guess that more than 95% of FPGA device is just array of SRAM cells. > > Does someone aware of these data? > Thank you again. Your number is exaggerated, but what is your point? What do you try to prove, argue, challenge, understand ??? FPGA technology is no big secret. It is well-understood in the technical, commercial and academic communities. Peter AlfkeArticle: 123608
siliconbluetechnology@yahoo.com wrote: > Hello, > > Silicon Blue Technologies is an FPGA startup located in Sunnyvale CA. > The FPGA product it is developing has ultra low power consumption and > is targeted to low power applications. > > The company is seeking some commercial designs in the form of Verilog > and/or VHDL designs to test its software and FPGA architecture. > > Please provide your input if you are interested in the product or have > testcases which can be useful to test both FPGA hardware and software > capabilities. > > Thank you. > > Silicon Blue Technologies > http://www.siliconbluetech.com This is a little light on information. No mention of size/pincount of the FPGAs, so no one knows if their app is too small, or too large. There are plenty of Open Source designs out there, so why not grab a USB core, an Ethernet core, and a 32 Bit uC core (Mico32?), and then run up a power prediction on that and compare it with both other RAM FPGAs, and also devices like Atmel's Mid-volume CAP7/CAP9 series, and higher volume Microcontrollers. I did see this news : ["QuickLogic Corp. is backing away from the FPGA market, saying it will instead focus on an ASSP-like sector called customer specific standard products (CSSPs)"] -jgArticle: 123609
On Aug 30, 1:21 pm, Andy <jonesa...@comcast.net> wrote:
> Weng,
>
> I'll say this: I admire your tenacity.
>
> The coding Jim provided was to illustrate a way, with today's standard
> (not including PSL), to code your orif example such that the synthesis
> tool would give the equivalent implementation.
>
> Since you seem to be in favor of powerful and concise ways to
> implement this, an even better way to code this function would be to
> use arrays, particularly with more than just 6 choices involved:
>
> process (reset, clk) is
> variable: temp : std_logic_vector(outbus'range);
> begin
> if reset = '1' then
> outbus <= (others => '0');
> elsif rising_edge(clk) then
> temp := (others => '0');
> for i in e'range loop
> temp := temp or (e(i) and data(i));
> end loop;
> if unsigned(e) /= 0 then
> outbus <= temp;
> end if;
> end if;
> end process;
>
> Now, if we are allowed to extend the standard (not the language), with
> the use of a synthesis-aware assertion and zero_one_hot() function,
> this can be greatly simplified, while also making it more functionally
> clear:
>
> process (reset, clk) is
> begin
> if reset = '1' then
> outbus <= (others => '0');
> elsif rising_edge(clk) then
> for i in e'range loop
> if e(i) = '1' then
> outbus <= data(i);
> exit;
> end if;
> end loop;
> assert zero_one_hot(e);
> end if;
> end process;
>
> However, a loop of if/then statements is not compatible with your
> proposed orif keyword.
>
> Therefore, we have a more powerful and concise example of coding this
> function with zero_one_hot() than is possible with a new keyword
> 'orif'.
>
> So, zero_one_hot() can do everything 'orif' can do and more, while
> doing so more concisely, and not requiring a language syntax change.
>
> Why do we need 'orif'?
>
> Andy
Hi Andy,
I would like to answer your this question.
process (reset, clk) is
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
for i in e'range loop
if e(i) = '1' then
outbus <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(e);
end if;
end process;
Good example !
you have claimed in other place the following:
1. define e;
2. Assign e's every bit a combinational value;
You have missed the most important things: what conditions they are !
Here is an example from my coding that shows orif usage: in-line
programming capability
if(TWindowLoad_E0_L_H and nC_BE_R0(3) = '0') then
TWindow_3(10 downto 8) <= AD_R0(26 downto 24);
orif(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0') then
TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
end if;
Please ask Verilog group why they introduce 'unique' keyword to
provide in-line programming tool to specify the mutually exclusiveness
if I don't misunderstand as following example shown by Marcus:
| module unique_if;
| bit clk, reset;
|
| logic E0, E1, E2, E3, E4, E5;
| logic [0:5] E;
|
| logic [7:0] OutBus;
| logic [7:0] Data [0:5] = '{ 0, 1, 2, 3, 4, 5 };
|
|
| initial begin
| clk <= 0;
| reset <= 1;
| #20ns;
| reset <= 0;
| end
|
| always clk = #5ns ~clk;
|
| always @(posedge clk, posedge reset) begin
| if(reset)
| OutBus <= 0;
| else begin
| void'(randomize(E) with {
| E inside { 1, 2, 4, 8, 16, 32, 10 }; // note the
occurence of 10
| });
|
| {E0, E1, E2, E3, E4, E5} = E;
|
| unique if(E0) OutBus <= Data[0];
| else if(E1) OutBus <= Data[1];
| else if(E2) OutBus <= Data[2];
| else if(E3) OutBus <= Data[3];
| else if(E4) OutBus <= Data[4];
| else if(E5) OutBus <= Data[5];
| end
| end
|
| endmodule : unique_if
Weng
Article: 123610Symon wrote: > "maxascent" <maxascent@yahoo.co.uk> wrote in message > news:ifidnQIYxf3YUUvbRVn_vw@giganews.com... >> Hi >> >> If I am designing a pcb using impedance controlled layers can I treat the >> power planes as a reference layer as well as the gnd layers? >> >> Cheers >> >> Jon > > Hi Jon, > Yes. But with a caveat. When your signals switch reference layers, make sure > there is a path for the reference current. > > E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal goes > from layer 1 to 6 through a via, you should have a bypass cap bewteen power > and ground near this via. Think of your signal as differential, the > complementary signal being the reference. > > It's for this reason that I long ago ditched power planes and use multiple > ground planes instead. I route and/or copper pour powers. Then the bypass > cap in the example I gave can be replaced by a ground via, because layer 5 > is ground in my PCB. > > HTH., Syms. > > I have a number of pretty pics I made to illustrate the issue. I'll put 'em on a.b.s.e tomorrow sometime. As an aside, at high speeds (which I define as having a track longer than 1/4 rising/falling edge, YMMVG), there is no such thing as 'ground'. The ground plane is a signal layer insulated by copper ;) [Although it helps to keep large power currents away from the high speed return paths]. Cheers PeteSArticle: 123611
> You do need to use a configuration cycle to write to the command > register to enable memory or I/O transfers when initialising the core; > see "stimulus.vhd" in the ping_tb testbench for example. > > - Brian Thank you Brian for clearing that bit for me. I didn't know that I have to initialise the core. Maybe that's the reason why I still couldn't get the Device and Vendor ID after synthesizing the core on my development board. Can anyone explain when and how is the "configuration cycle" need to be done for the initialising process? Thank you in advance.Article: 123612
Hi Jim and Colin, Your assert zero_one_hot() (or any other function name) may not be the one I want. Your zero_one_hot() tells simulator to check if all bits meet the zero or one active conditions. If it meets, return '1', otherwise return '0'. The code doesn't have any AUTHORITY to let VHDL compiler to do any optimization, and it just has the AUTHORITY to let simulator run the function and check its correctness. An assertion function is not authorized to transfer information to VHDL compiler ! In strict computer language meaning, any VHDL compiler has no OBLIGATION to do optimization work based on information of inputs from zero_one_hot() code even though they are designed to do so for the purpose. What an assertion function can do is to return its value: true or false, how can it be used to transfer mutually exclusive information to VHDL compiler? IT IS ILLEGAL ! If so, that is totally different from 'orif' meaning: for 'orif' It not only gives the mutually exclusive information, but also orders: 1. VHDL compiler to do code optimization based on the mutually exclusive information; 2. Simulator to check if related mutually exclusiveness is met. Because it is a keyword, it has AUTHORITY to issue two different commands to VHDL compiler and simulator, respectively, and the orders are mandated and it has no code to execute. Finally I got my point. WengArticle: 123613
On Aug 30, 3:22 pm, Andy Peters <goo...@latke.net> wrote: > On Aug 30, 10:35 am, EEngineer <mari...@gmail.com> wrote: > > > > > > > On Aug 30, 11:12 am, Gabor <ga...@alacron.com> wrote: > > > > On Aug 30, 10:14 am, EEngineer <mari...@gmail.com> wrote: > > > > > On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote: > > > > > > On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > > > > > > > "EEngineer" <mari...@gmail.com> wrote in message > > > > > > >news:1188426999.764557.233750@k79g2000hse.googlegroups.com... > > > > > > > > there are also UCF lines: > > > > > > > > NET ctrl_data<*> SLEW = FAST; > > > > > > > NET ctrl_data<*> DRIVE = 2; > > > > > > > NET ctrl_data<*> IOSTANDARD = LVCMOS33; > > > > > > > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not > > > > > > something that will make your outputs happen coincident with your clock, > > > > > > it's a specification that will simply fail in the place & route and timing > > > > > > analyzer. Take a look. The fastest your outputs will go depend on how fast > > > > > > an IOB register can deliver its output relative to your global clock. These > > > > > > numbers are documented and easy to prototype. > > > > > > > Second, the 2 mA drive level will give you a slower rise/fall. The skew in > > > > > > your output signal time can - depending on your load - be a noticeable time > > > > > > difference. > > > > > > > Third, the logic analyzer is an asynchronous device which will usually > > > > > > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns > > > > > > difference not explained by the test equipment. > > > > > > > Please find the online documentation (or a Xilinx class) that describes what > > > > > > you can and cannot do with constraints. This fundamental information > > > > > > usually is only understood after an engineer can't understand why their > > > > > > design isn't working. Learn it. > > > > > > If you need your outputs to have very low skew, your only hope > > > > > is to place all of the output flip-flops in the IOB's (IOB=TRUE > > > > > attribute on the flip-flop or net). You can also globally place > > > > > registers in IOB's using the synthesis and map properties. If > > > > > your outputs are generated by fabric flip-flops it is very hard > > > > > to get your skew below 2.5 nS > > > > > > By the way, why do you need such low skew on these lines? Is the > > > > > driven device asynchronous with respect to your clock? > > > > > > Regards, > > > > > Gabor > > > > > I need those signals to control the analog CMOS circuit that has a > > > > requirement for some signals not to overlap - this happens when the > > > > output from the FPGA is not synchronous enough. > > > > These signals will never be "synchronous enough" to guarantee zero > > > overlap when changing on the same clock cycle. Use a faster clock > > > if you need to, but certainly add a clock cycle between assertion > > > of signals that must not overlap. > > > Yes, I was thinking of using 16 times faster clock to add one clock > > cycle in between, but I have checked signals with the 500MHz scope > > (10Mohm, 9.5pF probes) and it looks like that digital analyser is > > giving misleading waveforms - there is almost no delay between these > > two signals (less then 1ns). The rise time is same for both signals, > > and this can be improved by increasing the drive in UCF file from the > > minimum 2mA, I don't know the load yet. > > You might want to learn how a logic analyzer works. It sounds like > your analyzer has a 400 MHz sample clock because of your noted 2.5 ns > uncertainty. This sample clock is of course asynchronous to your > circuit. So even if your FPGA's outputs are skewed less than 1 ns (as > you point out), that window might include the logic analyzer's sample > point, and as such signals that are in reality only 500 ps apart > appear on the analyzer to be 2.5 ns apart. > > So you should ensure that all of your signals are registered by a low- > skew clock in the IOBs and ensure that your PCB routing has equal > length lines from the FPGA to the load. This should result in quite > good skew matching. Also make sure the output s set to FAST, and > increase the drive strength. Read your timing analyzer's report for I/ > O clock-to-out times. > > And if the requirement is to ensure that two outputs are never enabled > simultaneously, then do as Gabor says and insert a one-clock dead time > between the deassertion of one output and the assertion of the other. > > -a- Hide quoted text - > > - Show quoted text - 2.5ns did not bother me, as that is the finest resolution of the logic analyser. But 5ns did bother me as that is longer than the sampling resolution. Scope has given me more precise reading - propagation dealy is 700ps and the rise and fall times for both the signals aprox. 2.5ns which is perfectly fine.Article: 123614
On Aug 30, 9:10 am, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote:
> On Aug 30, 6:00 am, fazulu deen <fazulu.v...@gmail.com> wrote:
>
> > Jon Beniston wrote:
> > > On 30 Aug, 10:21, fazulu deen <fazulu.v...@gmail.com> wrote:
> > > > Hai all,
>
> > > > Can any one suggest with an example how to run c++ code in modelsim
> > > > simulator...I didnt understand the example mentioned in modelsim us=
er
> > > > guide..Anyone tried this??
>
> > > What didn't you understand about it?
>
> > >linking was not clear to me and also in my case while simulating the c=
++ it will output a test file that has be red by the verilog code...both c+=
+ and verilog is independent and c++ should be first before verilog after t=
he file is obtained from the c++ simulator the verilog will start....how th=
is can be achieved
>
> Fazulu,
>
> If I understand you want to fire-off a thread in C++ and then invoke
> the verilog in msim. While I am not sure this could be done but I
> think for all practical purposes you can model your system so that
> your logic design (verilog sim) starts first and then invokes C++
> routines that comprise your system environment. I followed the
> commands and guidelines shown in msim's documentation for visual c.
> And that worked for me. What did not work was the cygwin commands
> they had listed.
>
> -sanjay
Here is the page from msim's manual - although I doubt if you can
still make the C++ code execute first. Arguable you can execute the C+
+ code at time 0. But you still have to call launch vsim first after
which it is going to execute c++ objects from the dll.
qverilog
The qverilog command compiles (vlog), optimizes (vopt), and simulates
(vsim) Verilog and SystemVerilog designs in a single step. It combines
the compile, elaborate, and simulate phases together, as some users
may be accustomed to doing with NC-Sim. This command is provided to
ease these users' transition to QuestaSim.
The qverilog command invokes vlog, vopt, and then vsim. All standard
vlog (and vopt) arguments are supported and are applied directly to
the qverilog command line. All vsim options are supported and are
applied through the qverilog -R argument.
You can directly enter either C or C++ file onto the qverilog command
line. QuestaSim automatically processes them using the SystemVerilog
Direct Programming Interface (DPI). Refer to "DPI and the qverilog
Command" for details. If your design contains DPI export tasks or
functions, it is recommended that you use the vlog/vsim flow.
You can invoke the GUI by specifying the -gui argument through the
qverilog -R argument.
By default, qverilog runs the simulation and quits automatically by
invoking an implicit "run -all; quit -f". However, if you invoke
qverilog with -do, -gui, or -I, qverilog invokes the simulator and
keeps it open until you explicitly quit the tool.
The qverilog command creates a work library named work in the current
directory, if not present already.
The command arguments listed below are only those unique to the
qverilog command. This command also supports all vlog command
arguments.
Syntax
qverilog [[<vlog_and_vopt_options>]] [-ccflags "opts"] [-gui] [-l
<logfile>] <filename>
[-ldflags "opts"] [-R <vsim_options>] [-work <library_name>]
Arguments
* [<vlog_and_vopt_options>]
All vlog and vopt options are supported. For example, if you are
running qverilog on a SystemVerilog design, you need to add the -sv
argument to the command line.
* -ccflags "opts"
Specifies all C/C++ compiler options. Options are in quotes. Optional.
For -ccflags and -ldflags, qverilog does not check the validity of the
option(s) you specify. The options are directly passed on to the
compiler and linker, and if they are not valid, an error message is
generated by the compiler/linker.
* -gui
Simulates the design using the ModelSim GUI.
* -l <logfile>
Creates a logfile/transcript compatible with vlog's -l logfile
argument. Optional. If omitted, a default transcript called
qverilog.log is created that collects the output from vlog, vopt, and
vsim.
* <filename>
Specifies the name of the Verilog or C/C++ source code file to
compile. One filename is required. Multiple filenames separated by
spaces may be entered. Wildcards may be used. In the case of C files,
they are automatically processed as DPI code.
* -ldflags "opts"
Specifies all linker options in quotes. Optional.
For -ccflags and -ldflags, qverilog does not check the validity of the
option(s) you specify. The options are directly passed on to the
compiler and linker, and if they are not valid, an error message is
generated by the compiler/linker.
* -R <vsim_options>
Specifies valid vsim arguments to be applied to the simulation. All
vlog and vopt arguments must come before -R is specified, as all
arguments specified after -R are interpreted as vsim arguments.
* -work <library_name>
Specifies a logical name or pathname of a library that is to be mapped
to the logical library work. Optional. By default, the compiled design
units are added to the work library. The specified pathname overrides
the pathname specified for work in the project file.
Examples
* Compile, optimize, and simulate the specified files. The C/C++
code contained in the d.c file is processed as DPI code, creating a
shared object, and loading it into vsim at runtime. Creates a logfile
named "logfile" and opens the QuestaSim GUI with the simulation loaded
and ready to run.
qverilog -l logfile a.v b.v c.v d.c -R -gui
Questa SV/AFV Reference Manual, 6.3a
=A9 1991-2007 Mentor Graphics Corporation. All rights reserved.
Browser Requirements
Article: 123615"Guru" <ales.gorkic@email.si> wrote in message news:1188464373.046442.162640@19g2000hsx.googlegroups.com... > Hi all, > > We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB > x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as > possible the DDR termination presents a problem. Since the Spartan3E > does not have DCI, termination on chip is not possible. This means > that 44 termination resistors should be added and maybe a VTT power > source. The other problem is that according to MIG we should connect > DDR to two banks. > > Any good suggestions? > Is it possible to eliminate termination resistors? > > Cheers, > > Guru > First, I would suggest changing your newsgroup alias to something other than "Guru" if you're asking whether or not you can eliminate terminations. How about "Have Lots To Learn"? You must meet setup and hold requirements of the data and control lines, meet the rise/fall time and monotonicity requirements of the clocks and strobes, and not violate the overshoot and undershoot specs on all signals for the FPGA and RAM. That's all there is to it. Get a simulator and determine what you need for your particular FPGA, RAM, and board layout restrictions. If you're going to skimp on the terminations then this is the only way to do it. BobArticle: 123616
I just need to know some technology data, for example, "die size" and "LUT size", in order to compare different designs. As far as I know, these technology data are not available anywhere.Article: 123617
Hi, i'd like to readback all the contents of an XC3S500E via the JTAG interface. Because this option is not implemented in the iMPACT-tool (well, it is implemented via the verify-option, but the readback data cannot be stored to a file), i tried to extend xc3sprog [1] to readback capability (that is extending the xc3sprog.cc) My question is, what commands are to be send to the Spartan 3E, because I wasn't able to find it on the Xilinx webpage, yet, although there are user guides for the Spartan 2(E)[2] and the Virtex[3] series. The opcodes used via the SerialMAP-interface are documented in [4], the JTAG Configuration Mode is explained in [5]. Any help would be appreciated. Greetings Benni [1] XC3SPROG http://sourceforge.net/projects/xc3sprog [2] XAPP176 http://www.xilinx.com/bvdocs/appnotes/xapp176.pdf [3] XAPP139 http://www.xilinx.com/bvdocs/appnotes/xapp139.pdf [4] XAPP452 http://www.xilinx.com/bvdocs/appnotes/xapp452.pdf [5] UG332 http://www.xilinx.com/bvdocs/userguides/ug332.pdfArticle: 123618
On 29 Aug, 22:49, "asic1...@gmail.com" <asic1...@gmail.com> wrote: > What does SDF, and Back-annotation/Forward annotation mean? How is an > SDF File generated and by which tool? > > Can someone explain how to do synthesis and what tools/file > extensions > (.sdf, .lib etc) mean? The Standard Delay Format (SDF) file stores the timing data generated by. EDA tools for use at any stage in the design process. www.eda-stds.org/sdf/sdf_3.0.pdf SDF can be generated by most ASIC synthesis, P&R or STA tools. Accuracy will vary though depending upon which stage in the design process you are). As to how to perform synthesis, read the user guide for your synthesis tool. Cheers, JonArticle: 123619
"John_H" <newsgroup@johnhandwork.com> wrote in message news:13de6b5q88e3ke1@corp.supernews.com... > "PeteS" <axkz70@dsl.pipex.com> wrote in message > news:H-ydnSZMEttzlkrbnZ2dnUVZ8vidnZ2d@pipex.net... > <snip> >> >> I have a number of pretty pics I made to illustrate the issue. I'll put >> 'em on a.b.s.e tomorrow sometime. >> >> As an aside, at high speeds (which I define as having a track longer than >> 1/4 rising/falling edge, YMMVG), there is no such thing as 'ground'. The >> ground plane is a signal layer insulated by copper ;) >> [Although it helps to keep large power currents away from the high speed >> return paths]. >> >> Cheers >> >> PeteS > > Since without a ground one has a dipole antenna, could you qualify what > you mean? The impedance of the plane is measured in units of picoHenry > per square so it's not a solid ground, certainly, but without a ground > we'd be in a world of hurt at these high frequencies. > I think Pete means that at high frequencies the skin effect means that the current in the plane is all on one surface of the plane. Thus the bulk of the plane might as well be an insulator. Or something like that? Cheers, Syms.Article: 123620
"Pasacco" <pasacco@gmail.com> wrote in message news:1188548197.323123.43310@i13g2000prf.googlegroups.com... >I just need to know some technology data, for example, "die size" and > "LUT size", in order to compare different designs. > As far as I know, these technology data are not available anywhere. > > What sort of engineer are you? For God's sake man, get a hammer, smash some FPGAs open, and examine the wreckage with a microscope. HTH., Syms. p.s. Do FPGAs blend? ;-)Article: 123621
Benni V. <benniv.sep08@googlemail.com> wrote: > Hi, > i'd like to readback all the contents of an XC3S500E via the JTAG > interface. Because this option is not implemented in the iMPACT-tool > (well, it is implemented via the verify-option, but the readback data > cannot be stored to a file), i tried to extend xc3sprog [1] to > readback capability (that is extending the xc3sprog.cc) > My question is, what commands are to be send to the Spartan 3E, > because I wasn't able to find it on the Xilinx webpage, yet, although > there are user guides for the Spartan 2(E)[2] and the Virtex[3] > series. > The opcodes used via the SerialMAP-interface are documented in [4], > the JTAG Configuration Mode is explained in [5]. > Any help would be appreciated. > Greetings > Benni > [1] XC3SPROG http://sourceforge.net/projects/xc3sprog > [2] XAPP176 http://www.xilinx.com/bvdocs/appnotes/xapp176.pdf > [3] XAPP139 http://www.xilinx.com/bvdocs/appnotes/xapp139.pdf > [4] XAPP452 http://www.xilinx.com/bvdocs/appnotes/xapp452.pdf > [5] UG332 http://www.xilinx.com/bvdocs/userguides/ug332.pdf Another source of information are the BSDL files. Find them in the ISE directory under spartan3e/data for e.g. the XC3SE.You will find the CFG_IN command the progalgxc3s.cpp uses for programming. The BSDL file also knows about a CFG_OUT command that could probably be used for readback. Compare with the BSDL files for the S2(E) and try out to do similar. Hope this helps -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 123622
Jim, In news:13ddnbc8cckdr7b@corp.supernews.com timestamped Thu, 30 Aug 2007 08:08:26 -0700, Jim Lewis <jim@synthworks.com> posted: |-------------------------------------------------------------------------------------------------| |"Colin Paul, | |[..] | |> That would be true for plain VHDL without PSL, but he posted as if | |> zero_one_hot() is now part of VHDL from PSL (but it is not in my PSL | |> reference manual, unlike onehot0) so that would not necessarily | |> require that a VHDL identifier be changed. From the PSL standard: | |> "[..] | |> | |OOPS. I missed that. I had meant to reference the PSL function onehot0." | |-------------------------------------------------------------------------------------------------| Muw wah hah hah, all shall bow down to my superiority. |-------------------------------------------------------------------------------------------------| |"[..] | | | |While it is possible that syntax could be given a similar | |interpretation, I am not sure it would be a good thing. | | | |Cheers, | |Jim" | |-------------------------------------------------------------------------------------------------| If we ever need to consider it, we can assess the pros and cons then. Cheers, Colin PaulArticle: 123623
Hi all, I'm facing a problem with Xilinx Coregen blockram fifo. At some point I want to reset it with a signal generated in a state machine. The reset makes the internal pointers in the FIFO to point to 0 address. However, the address stabilizes to 0 too late, right at the next rising edge of the clock that generated the reset signal. This produces a setup violation on the address port of the blockram. I thought TRCE would detect the violation after my design is placed and routed, but this is not the case, not even setting the "ENABLE = reg_sr_q;" constraint in the UCF file. I know my design will still work, and the output from the block cycle will remain in the unknown state only for one cycle, but I would like to correct it in a more elegant way. I don't want to see those warnings in modelsim anymore. What approach would you suggest? Thanks in advance.Article: 123624
On Thu, 30 Aug 2007 19:05:59 -0700, Ace <yasirmm@gmail.com> wrote: > >> You do need to use a configuration cycle to write to the command >> register to enable memory or I/O transfers when initialising the core; >> see "stimulus.vhd" in the ping_tb testbench for example. >> >> - Brian > >Thank you Brian for clearing that bit for me. > >I didn't know that I have to initialise the core. Maybe that's the >reason why I still couldn't get the Device and Vendor ID after >synthesizing the core on my development board. Can anyone explain when >and how is the "configuration cycle" need to be done for the >initialising process? Read the testbench example I suggested. But this doesn't explain why you can't get the Device/Vendor ID, because you read these through configuration cycles. When you can read these IDs, you can then use more configuration cycles to initialise the core. This means writing addresses to your Base Address Registers, and permission to perform memory or I/O cycles to the Command/Status register. Only after that, can you perform real memory or I/O transfers to the device. But if you can't read the Device/Vendor IDs, you have another problem. Did you read the Device/Vendor IDs in simulation? If not, get that working first. - Brian
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