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
Zoran, > somewhere on the board is 3.3V to 5.V converter, I didn't pay much > attention about that. I'll have to look about that Although this thing > obout this board and fpga is confusing, I have more wories about this > warring that I am getting from the quartus. It clearly says that this > pin constantly geting Vcc on it. I could bet that this is some > problem, not on the board. Mybe on the fpga is some pull up resistor > and it can't be turned off. I don't know what else could be. I have looked at the board's schematics. There are tons of pullups to 5V, so you probably are using one of these pins. How have you chosen your pins if you have chosen them at all? With regards to what Quartus says, I haven't touched Altera for quite a number of years now, so I am not an expert here... Perhaps someone else would be better equipped to answer why it is using open-drain output and what exactly the warning means... /MikhailArticle: 123551
"MM" <mbmsv@yahoo.com> wrote in message news:5jmq58FcbhqU1@mid.individual.net... > > With regards to what Quartus says, I haven't touched Altera for quite a > number of years now, so I am not an expert here... Perhaps someone else > would be better equipped to answer why it is using open-drain output and > what exactly the warning means... > Actually after having read the warning one more time and having re-read what Altera tech support guy told you I think I now understand what it all means. VCC doesn't mean VCC, it means logic '1', and it is not applied to the pin itself, it is applied to the datain port of the IO buffer, which happens to be an open-drain buffer, and an Altera open-drain buffer when fed logic '1' will have a transistor closed resulting high-impedance. So, I think everything works as it should and the 5V measured results from an external pullup resistor. Just study your schematics... /MikhailArticle: 123552
Hi All, I am new to FPGAs and my main interest is implementation of some signal processing algorithms on FPGAs. For testing the MEMEC (DS-BD- V2MB1000) board which has a xc2vc1000 fpga on it along with a xc18v04, I was trying to write a simple module. I am using the impact Parallel IV cable for download of my code. I started with a simple VHDL code for a counter to be displayed on 7- segment display. Since it did not work, I slowly started removing code and now I have a single line in the architecture architecture board of testLed is begin led <= '1'; end board; The "led" is the user led provided on the board. Don't think it can get any simpler. But even this doesn't seem to work. I am using the JTAG interface available on the board. The boundary scan is working perfectly and detecting the FPGA & PROM. After bypassing the PROM, I am loading the bit file on the FPGA. I am using Xilinx ISE Foundation 6.2 & XST for synthesis and have also assigned the pins through PACE. The edit contraints show the following text. NET "led" LOC = "A9" Any suggestions regarding the possible cause of what I may be missing will be welcome. Regards PiyushArticle: 123553
Good Morning,
thanks for your answers. I will try to do some timing verification
again.
But first here are the answers to your questions.
"Clarify please what kind of signal and how you change it."
=> I tried to insert status bits to make the states of the
FSM visible with the oscilloscope.
=> Or use direct the states (coding by hand) to debug
the FSM.
"...then the design doesn't function any more."
=> it seems that the state machine does not start. The start condition
depends only on one
input signal. This input signal is generated with a write with the DSP
to a register. With this
write a pulse of one clock cycle is generated that triggers the FSM.
The DSP is connected to the
FPGA with a synchronous interface.
What does it mean to "use direct routing"? How can I do that?
I did a lot post P&R simulations, but I can't see the error.
Markus
Article: 123554
On Aug 29, 2:10 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> I think you've misinterpreted what's happening. In your original example,
> the 'cnt' signals don't need to get back to the clock enable input in one
> cycle. Only the signal 'en' does. As long as 'en' gets to the FFs in time,
> whatever the CNT signals are doing does not matter a jot.
I suggest that you (and all others who don't understand why I'm making
a fuss) take five minutes to try out the module I began with, along
with the corrected constraints I suggested for solution. Implement
this on the Xilinx tools, require a VERBOSE timing report, and go
through the paths belonging to "ts_no_multipath". (To make life
easier, I've copied them down at the end of this message)
These are the problematic paths, which arrive at the relevant flip-
flop's CE, and would be wrongly relaxed to four cycles, had it not
been for the correction.
And after making this correction on real-life designs I can tell you
that this is not a theoretic problem, even though I have to admit that
I've never experienced any FPGA malfunction which I could relate to
this.
But please, try this out.
Eli
------------------------------------------------------
top.v follows:
module top(clk, cnt);
input clk;
output [15:0] cnt;
reg [15:0] cnt;
reg [1:0] en_counter;
reg en;
always @(posedge clk)
begin
en_counter <= en_counter + 1;
en <= (en_counter == 0);
end
always @(posedge clk)
if (en) // This is the "clock enable"
begin
// This runs only once in four clocks
if (cnt != 16'hffff)
cnt <= cnt + 1;
end
endmodule
---------------------------------------------
top.ucf follows:
NET "clk" TNM_NET = "clk";
TIMESPEC "TS_clk" = PERIOD "clk" 10 ns HIGH 50 %;
NET "en" TNM = FFS "tgrp_en";
TIMESPEC "ts_multipath" = FROM "tgrp_en" TO "tgrp_en" "TS_clk" * 4;
PIN "*.CE" TPSYNC="tgrp_ces";
TIMESPEC "ts_no_multipath" = FROM "tgrp_en" TO "tgrp_ces" "TS_clk";
Article: 123555I thinks something is finaly clear to me:). You must be right. I mean, it has to be it. When I was chosing my pins I didn't py much attention about that. Actualy I just piked the first from one of this conectors. I am now seeing this board and I am not shure how to eliminate this pull up, if there is any chance to eliminate it. But now, I am almost 100% shure that this has to be it and nothing else. Mikhail, Your help was raly great, and I can't say You, how much I am thankful for all. Zoran MM wrote: > "MM" <mbmsv@yahoo.com> wrote in message > news:5jmq58FcbhqU1@mid.individual.net... > > > > With regards to what Quartus says, I haven't touched Altera for quite a > > number of years now, so I am not an expert here... Perhaps someone else > > would be better equipped to answer why it is using open-drain output and > > what exactly the warning means... > > > Actually after having read the warning one more time and having re-read what > Altera tech support guy told you I think I now understand what it all means. > VCC doesn't mean VCC, it means logic '1', and it is not applied to the pin > itself, it is applied to the datain port of the IO buffer, which happens to > be an open-drain buffer, and an Altera open-drain buffer when fed logic '1' > will have a transistor closed resulting high-impedance. So, I think > everything works as it should and the 5V measured results from an external > pullup resistor. Just study your schematics... > > /MikhailArticle: 123556
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, GuruArticle: 123557
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 user guide..Anyone tried this?? regards, fazalArticle: 123558
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 user > guide..Anyone tried this?? What didn't you understand about it? JonArticle: 123559
Piyush Kaul <piyushkaul@gmail.com> writes: > Hi All, > Hi Piyush, > > architecture board of testLed is > begin > led <= '1'; > end board; > > The "led" is the user led provided on the board. > > Don't think it can get any simpler. But even this doesn't seem to > work. I am using the JTAG interface available on the board. The > boundary scan is working perfectly and detecting the FPGA & PROM. > After bypassing the PROM, I am loading the bit file on the FPGA. > > I am using Xilinx ISE Foundation 6.2 & XST for synthesis and have also > assigned the pins through PACE. The edit contraints show the following > text. > > NET "led" LOC = "A9" > A few things come to mind... I assume that *is* the right location? Do you have the schematics for the board? Sometimes the LEDs are wired up so that they come on if the pin is *low*... Do you know that the board works at all - have you got any pre-done designs you could try on it? Sorry not to have more specific ideas! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 123560
<eli.billauer@gmail.com> wrote in message news:1188458760.939432.256410@g4g2000hsf.googlegroups.com... > On Aug 29, 2:10 pm, "Symon" <symon_bre...@hotmail.com> wrote: > >> I think you've misinterpreted what's happening. In your original example, >> the 'cnt' signals don't need to get back to the clock enable input in one >> cycle. Only the signal 'en' does. As long as 'en' gets to the FFs in >> time, >> whatever the CNT signals are doing does not matter a jot. > > I suggest that you (and all others who don't understand why I'm making > a fuss) take five minutes to try out the module I began with, along > with the corrected constraints I suggested for solution. Implement > this on the Xilinx tools, require a VERBOSE timing report, and go > through the paths belonging to "ts_no_multipath". (To make life > easier, I've copied them down at the end of this message) > > These are the problematic paths, which arrive at the relevant flip- > flop's CE, and would be wrongly relaxed to four cycles, had it not > been for the correction. > Hi Eli, Of course, I think I DO understand why you're making a fuss, but think you don't need to worry! :-) Please, instead of following your suggestion, let me spend the five minutes to allow me to try again to persuade you of the error of your ways! You correctly state that the CNT signals have a logical path to the CE pin of the counter which generates them. Let's call the signal at this CE pin CNT_CE. This fact alone causes you to believe that these CNT signals must get through the logic which generates CNT_CE in one cycle. However, this is _NOT_ true in this case. The signal EN, which is high for one in every four cycles of the clock, is gated into this logic that makes CNT_EN. Whenever EN is low, the signal CNT_CE is low, no matter what the CNT signals are. So, as long as the signal EN gets from the FF it's generated in to CNT_EN and the CE pins of the CNT counter, all will be well, provided the CNT signals get through the logic by the time the EN signal next goes high. Your original constraints are fine for your situation. If this weren't the case, multi-cycle paths wouldn't work. Also, and I'm sure you realise this, there is nothing magical about the CE pin, it's just another logic input that controls a mux. It's easy(ish) for you to try this out. I suggest that you (the person asking the group for input ;-)) get your simulator out, write your HDL to add suitable simulated long delays to the CNT pins, and see what happens. I only wish I'd pointed this out to you 2 weeks ago, I may have saved you some effort. My excuse is I didn't read the OP thoroughly as it seems to have Hebrew characters in it that my viewer complains about. Finally, it is a pain in the arse when the synthesiser uses gated logic (that admittedly can save LUT usage) on the CE input if you have a very fast clock that needs clock enables. As I said in another post, Synplify has a switch called syn_direct_enable. This is great for fixing this problem. In VHDL:- attribute syn_direct_enable: boolean; attribute syn_direct_enable of EN : signal is true; HTH., Syms.Article: 123561
On 2007-08-30, Weng Tianxiang <wtxwtx@gmail.com> wrote:
|---------------------------------------------------------------------------------------------|
|"On Aug 29, 3:44 pm, Andy <jonesa...@comcast.net> wrote: |
|> On Aug 29, 11:46 am, Weng Tianxiang <wtx...@gmail.com> wrote: |
|> |
|> |
|> |
|> |
|> |
|> > On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> |
|> > wrote: |
|> |
|[..] |
|> > > On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote: |
|[..] |
|> |
|> > > [..] I think the intention would be clearer with different |
|> > > indentation. [..] |
|[..] |
|> > Hi Colin, |
|> > Thank you for your support. |
|> |
|> > You are the first big canon who gave full support behind the keyword |
|> > 'orif' and gets full understanding of its meaning. |
|---------------------------------------------------------------------------------------------|
Hello Weng,
I neither provided support for nor opposed your proposal, I simply
tried to clarify for Jim whether the appearances of elsif were typos.
I am indifferent.
However, you clearly have not understood any of the responses so far
in this thread. At least three alternatives not needing a new language
were shown to you:
a synthesis tool worth using should be able to determine how to
efficiently implement a design;
a case statement;
and
one-hot encoding or something similar using PSL instead of an
attribute.
The PSL approach is the only one you have tried to respond to. If you
can not prove that what you want to achieve can not be achieved
well otherwise, then you will find it difficult to convince people who
do not want too many ways to achieve one thing.
Your lack of appreciation for how the case statement is relevant and
other things you have revealed to us indicate that your depth of
understanding of VHDL needs to improve and this is also not helping
people to take you seriously. Please read at least two good books with
decent VHDL content, e.g. at least one of those listed on
WWW.Ashenden.com.Au
, and read the books you choose twice each.
|---------------------------------------------------------------------------------------------|
|"> > My fighting for 'orif' recognition is not for my personal purpose, it |
|> > is in the interest of HDL industry and academic world." |
|[..] |
|> > 3. As keyword 'orif' definition says, 'orif' only provides information |
|> > about mutually exclusive property among a group of conditions. |
|> > Compilers can do what they think is the best strategy as they want. |
|> > But for FPGA, the 'orif' perfectly refers to carry chain structure in |
|> > both Xilinx and Altera (I am not familiar with other FPGA products), |
|> > it is a wonderful thing, but should not be a burden or a blame, as |
|> > Jonathan indicated. |
|---------------------------------------------------------------------------------------------|
I appreciate that you are genuinely being noble, but please understand
that you should not insist that orif must be implemented as a carry
chain. The designer writes in a HDL and the optimizer in the synthesis
tool finds an efficient way to implement something. Something from a
HDL might not always be represented the same way, depending on many
issues too complicated to explain here. Please understand this example
from Andy:
|---------------------------------------------------------------------------------------------|
|"> Any synthesis tool that cannot figure out the code below (rewritten |
|> from your example, but in standard vhdl with elsif) indicates mutually |
|> exclusive conditions should be immediately uninstalled and returned to |
|> the vendor for a full refund! |
|> |
|> if(two_bits = "00") then |
|> ... |
|> elsif(two_bits = "01") then |
|> ... |
|> elsif(two_bits = "10") then |
|> ... |
|> else <-- equivalent to "when others =>" |
|> ... |
|> end if;" |
|---------------------------------------------------------------------------------------------|
No matter how you improve your proposal for orif, you can not refute
this point of Andy's.
Weng posted:
|---------------------------------------------------------------------------------------------|
|"> > > On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote: |
|[..] |
|> |
|> > > |--------------------------------------------------------------------------ญญ| |
|> > > |"[..] | |
|> > > | | |
|> > > |[..] The danger in adding new keywords is that they may | |
|> > > |conflict with a name (signal, ...) already used in someone's design | |
|> > > |and cause an old design to be a syntax error in the new language | |
|> > > |revision. This generally does not please people and means they | |
|> > > |have to add special handling for the file (compile flags). | |
|> > > | | |
|> > > |[..]" | |
|> > > |--------------------------------------------------------------------------ญญ| |
|> |
|> > > A newly introduced reserved word would be guaranteed to not conflict |
|> > > with old code by not being possible to misinterpret as a basic |
|> > > identifier (basic_identifier ::= letter { [ underline ] |
|> > > letter_or_digit), e.g. by starting with an underline or by containing |
|> > > a percentage sign. |
|> |
|> > > Best regards, |
|> > > Colin Paul |
|[..] |
|> > 3. "A newly introduced reserved word would be guaranteed to not |
|> > conflict |
|> > with old code" |
|> |
|> > Jim's opinion is that if you introduce a new keyword 'orif', then even |
|> > though 'orif' doesn't conflict with 'elsif', but it certainly would |
|> > conflict with old signal name orif. This can never be avoided." |
|---------------------------------------------------------------------------------------------|
This can easily be avoided as I had already showed: it would be legal
and easy to have a reserved word (e.g. _orif) which could never had
been used as a basic_identifier.
|---------------------------------------------------------------------------------------------|
|" But his |
|> > new function name zero_one_hot() still has the same possibility to |
|> > conflict with old signal function name zero_one_hot() if someone had |
|> > used it before, but he never mentioned his same possibility. |
|---------------------------------------------------------------------------------------------|
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:
"[..]
4.2.2 Keywords
Keywords are reserved identifiers in PSL, so an HDL name that is a PSL
keyword cannot be referenced
directly, by its simple name, in an HDL expression used in a PSL
property. However, such an HDL name can
be referenced indirectly, using a hierarchical name or qualified name
as allowed by the underlying HDL.
The keywords used in PSL are shown in Table 1.
[..]
onehot0
[..]
5.2.3 Built-in functions
PSL defines a collection of built-in functions that detect typically
interesting conditions, or compute useful
values, as shown in Syntax 5-20.
Syntax 5-20.Built-in functions
HDL_or_PSL_Expression ::=
PSL_Expression
PSL_Expression ::=
Boolean -> Boolean
| Boolean <-> Boolean
Built_In_Function_Call ::=
prev (Any_Type [ , Number [ , Clock_Expression ]] )
[..]
| onehot0 ( BitVector )
[..]"
|---------------------------------------------------------------------------------------------|
|"> The fact that orif must be indented from elsif, is a very poor way to |
|> indicate functional structure of code. [..]" |
|---------------------------------------------------------------------------------------------|
Andy,
Your example
enable := (others => '0');
for i in enable'range loop
if address = i then
enable(i) := '1';
end if;
end loop;
from news:1188329351.852738.51270@22g2000hsm.googlegroups.com is
easier to read with indentation than
enable := (others => '0');
for i in enable'range loop if address = i then enable(i) := '1'; end if; end loop;
and is condemning evidence against neither FOR nor IF.
|---------------------------------------------------------------------------------------------|
|"[..] |
|> zero_one_hot() can always be prefixed with the standard package name |
|> in which it is defined." |
|---------------------------------------------------------------------------------------------|
Andy,
Is zero_one_hot() defined in a package? Even if it is, Weng was
complaining that Jim complained that orif would clash with a
basic_identifier and Weng perceived this as hypocrisy as he thought
zero_one_hot() would also clash with a basic_identifier.
|---------------------------------------------------------------------------------------------|
|" Keywords, on the other hand cannot. I believe |
|> that tricks like '_' and '%' on the front of new keywords are a |
|> hideous hack, [..] |
|---------------------------------------------------------------------------------------------|
Actually _ would need to go to the front but % could go anywhere, not
that this would make you detest the ways in which new reserved words
can be added to VHDL (sorry to Verilog people reading this) with a
guarantee that old basic_identifiers will still be valid.
|---------------------------------------------------------------------------------------------|
|"[..] |
| |
|I can imagine if both methods, Jim's and mine, are introduced into |
|VHDL standard, I can bet with you: 99.9999% of engineers who use |
|mutually exclusive method to speed up their designs would use my |
|method. My basis is nobody who write 'if...eslif...end if' statements |
|today uses 2 separate parts as Jim suggested for zero_one_hot() to |
|write 'if...eslif...end if' statements. |
| |
|[..]" |
|---------------------------------------------------------------------------------------------|
Does the way that most reactions you have received are negative not
seem to indicate that maybe 99.9999% adoption of your proposal is
overly optimistic? It could be said that almost 99.9999% of people who
write in VHDL write the basic_identifier for detecting a clock edge
with "2 separate parts" even though a standard to use the
basic_identifier only once per detection was published alongside
VHDL93.
Regards,
Colin Paul
P.S. This thread is taking up a lot of time, I might not post denials
of mischaracterizations of me again until many days later as I need to
get other work done soon.
Article: 123562Jon 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 user > > 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 the file is obtained from the c++ simulator the verilog will start....how this can be achievedArticle: 123563
On Wed, 29 Aug 2007 18:54:31 -0700, Ace <yasirmm@gmail.com> wrote: >Hi, > >I realize that in cfg.vhd files generated by PCI32 LogiCore does not >have command register and status register. From Mindshare book, it >said it is "always mandatory" to supply this information. Does anyone >know what do I need to do/add? I don't believe you have to add anything; they are automatically there. If you look at the "signal description" section of the "implementation" PDF you will see a description of the command register bits made available to the user interface. This confirms that the register exists... 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. - BrianArticle: 123564
Hello! I would like to change the FPGA in this board to a bigger one, but I don't know if it's possible. I noticed in the datasheet ( http://direct.xilinx.com/bvdocs/publications/ds312.pdf ) that the 500 and 1200 versions are pin compatible (FG320), so my question would be whether it is enough to simple change it out, or I have to do something more with it? (The 4 Mbit platform flash on the board is enough for configuration; but if I would like to have a S3E1600, I would need 8 Mbit p.f.) I can see some smd capacitors next to the fpga, quite close... are they to survive the soldering process, or will I have to buy new ones, and solder them there?Article: 123565
The new xilinx forum now has a recent threads link. IMHO this makes the forum much more useful for contributors... http://forums.xilinx.com/xlnx/newthreadsArticle: 123566
> 1. So when i try doing this the program is not completely get written > and gets hanged in between. But when i generated raw bit files (using > - b option in bitgen) i am able to transfer the whole content , but > after downloading, the system is not functioning as expected ( no > change in the display). > The other thing is that the size of original .bit file is 158kB, > and .rbt file is 1356kB - so what makes the .rbt fle so big. I may have steered you wrong when I mentioned raw bitstreams; the terminology is sometimes misleading. The bitgen -b (Create Rawbits File) is *not* what you want, so the fact that the .rbt is enormous is irrelevant. > 2. I tried downloading .bin file (generated using - g binary : yes > option in bitgen) again the whole data is not getting transfered but > gets stuck up in between. but the size of this file is only 157kB with > header removed. The -b binary:yes option is indeed what you want, because it generates a regular bitstream without the human-readable header. The fact that the regular .bit and the binary .bin are nearly identical in size makes sense. So the question now is why the .bin download is not working correctly. The first thing I would do is try to download the .bit file to the board from iMPACT, as Sean suggested. You absolutely should get the correct results when you try that, and if you do not, you will have to verify that your design really does what it's supposed to do. Once you've verified that the .bit works correctly from iMPACT, you'll need to figure out why the .bin does not work correctly from your PowerPC code. Until you are able to feed the bitstream through the ICAP with no errors, you shouldn't expect the design to work. A few things to be aware of on that point: - Read http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/02e00d4ec0ef783e if you have not already done so. You can either correct XhwIcap_SetConfiguration(), or you can call a modified version of it. - Overwriting configuration frames that touch LUT RAM (including shift registers) or dual-ported BRAM resources can do Undefined Things. Which is to say that you could be killing your design unintentionally. (But perhaps PlanAhead protects against that; I'm not really sure since I don't use PlanAhead.) It's somewhat unlikely that this is the source of your problems, but it is possible. Furthermore, you may have to do what many of us do when approaching a new problem: Take a ridiculously simple design and try to debug it first. Driving an LED high or low is a time-tested favorite.Article: 123567
On Aug 30, 4:59 am, Guru <ales.gor...@email.si> wrote: > 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 If you're only driving a single chip with very short lines you can probably get away without termination on everything except the clock. I would suggest using SSTL2_I instead of SSTL2_II to avoid overdriving. Another approach is to just leave out the series termination on these signals and just add the parallel termination to Vtt. I've used the latter method with Virtex2 and an SO-DIMM without DCI on the data lines and SSTL2_I drive. A good argument for leaving out the series termination is any net where the driving stub (from the S3 to the resistor) is about the same length as the driven stub (from the resistor to the memory). Here the terminator is of dubious value. It's probably best to simulate your transmission lines, especially if you're planning to run the memory at its maximum speed of 166 MHz / DDR333. My V2 design ran at 133 MHz / DDR266. HTH, GaborArticle: 123568
On Aug 30, 1:45 am, markus.j...@de.bosch.com wrote: > Good Morning, > > thanks for your answers. I will try to do some timing verification > again. > But first here are the answers to your questions. > > "Clarify please what kind of signal and how you change it." > => I tried to insert status bits to make the states of the > FSM visible with the oscilloscope. > => Or use direct the states (coding by hand) to debug > the FSM. > > "...then the design doesn't function any more." > => it seems that the state machine does not start. The start condition > depends only on one > input signal. This input signal is generated with a write with the DSP > to a register. With this > write a pulse of one clock cycle is generated that triggers the FSM. > The DSP is connected to the > FPGA with a synchronous interface. > > What does it mean to "use direct routing"? How can I do that? > I did a lot post P&R simulations, but I can't see the error. > > Markus You haven't mentioned which part and tools you're using. Xilinx? Altera? The DSP is off-chip? Perhaps the "synchronous interface" isn't meeting input setup and hold requirements? Another thought is FSM implementation. In Xilinx tools you have to work very hard to force the implementation to use anything other than one-hot encoding. This has the unfortunate habit of going "zero-hot" when inputs are not properly synchronized. Bringing the state bit out to debug pins could possibly cause the FSM encoding to change, masking your problem. HTH, GaborArticle: 123569
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 JonArticle: 123570
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, GaborArticle: 123571
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.Article: 123572
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.Article: 123573
On Aug 30, 7:14 am, dormanpet...@gmail.com wrote: > Hello! > > I would like to change the FPGA in this board to a bigger one, but I > don't know if it's possible. Why are you not just buying the bigger one with the xc3s1600e ?Article: 123574
On 28 Aug., 13:23, Marcus Harnisch <marcus.harni...@gmx.net> wrote: > Weng Tianxiang <wtx...@gmail.com> writes: Weng, take a step back. First, not under all circumstances the carry chain implementation is the most efficient of the gated OR selector. For small number of inputs it fits into a single 6-LUT, for very large number of inputs the logarithmic delay of the tree will be better than the linear delay of the carry chain, even though the constants for the carry chain are better. Second, the only thing that your orif keyword thos, is a hint to the synthesizer that the behaviour is undefined for certain input combinations. You restrict the domain of the function. The following code has the same semantics: if E1 + E2 + E3 > 1 then -- (Lazy and incorrect VHDL type handling to shorten example, you will get the point) result <= (others => '-'); elsif E1 = '1' then result <= input1; elsif E2 = '1' then result <= input2; elsif E3 = '1' then result <= input3; else result <= (others => '0'); end if; You will however notice, that most synthesis tools will not utilize the optimization potential available from '-'. I am often annoyed by this. For example if you write an instruction decoder for a CPU, you do not care about the behaviour of the ALU for all instructions that use no ALU result. Specifying don't cares would greatly reduce the amount of logic for the decoder. This is an improvement that is far more versatile than your proposal and it is allready in the language. However most synthesis tools will replace all occurences of '-' with '0'. The reason behind this is that verification guys hate don't cares. For regression testing you wan't the hardware to behave the same if the specification did not change. '-' might be synthesized differently every time. For formal verification you definitely can't allow the freedom of don't cares. In most contexts verification is a far bigger problem then efficient implementation. If you really want the most efficient implemetation you should specify the detailed behaviour. assert (PSL formulation to guarentee mutual exclusiveness goes here); result <= (input1 and (result'range => E1) or (input2 and (result'range => E2) or (input3 and (result'range => E3); Telling the synthesis tool to implement wide ORs in carry chains is simpler than to introduce a new keyboard. This way other uses of wide ORs benefit aswell, as do users of other languages. Kolja Sulimma P.S.: Xilinx has a patent on implementing a wide OR using carry logic. There is no explicit license that grants you the right to distribute bitstreams that use that trick. Xilinx says, they do not want to sue anybody about that. But I bet Unisys had no intent to sue GIF users in the 80ies. But intentions can change. Do you want to bet your business on an informal declaration by Austin in a newsgroup?
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