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
"comp.arch.fpga" <ksulimma@googlemail.com> wrote in message news:1188287118.863429.148200@o80g2000hse.googlegroups.com... > On 28 Aug., 00:09, Andy <jonesa...@comcast.net> wrote: >> On Aug 27, 1:33 pm, Mike Lundy <novas0...@gmail.com> wrote: >> ..snip >> >> Then there are things like no deferred constants in synthesis still >> bother me, because there is no good reason for the limitation. Most >> synthesis tools do not support global signals either. > > The frustrating thing is, that there are papers out there that show > how simple > it is to greatly expanded the synthesizable subset. > > Some examples: > > The following code can be made synthesizable by a simple vhdl->vhdl > transformation. A preprocessor would suffice: > if rising_edge(clk) and enable='1' then ... Gated clocks are supported by most high-end synthesis tools. > > Why is there only a single wait statement allowed per process? If all > wait statements depend on the same clock signal it is relativly easy > to automatically create a state machine with one state per wait > statement. Precision supports multiple wait statement per process provided, as you mention they use the same clock, from the manual: "Multiple wait statements are supported in a process with some synthesis restrictions. All the control paths should have at least one wait statement and all of the wait statements should be identical with a single bit clock expression. The expression in the until condition must specify a leading or falling single clock edge. All assignments inside the process result in the creation of registers. Each register (flip-flop) is clocked with the single clock signal. There are a number of cases where multiple waits are synthesizable and resemble statemachine behavior. In Precision RTL Synthesis, multiple waits are supported". process -- no sensitivity list begin wait until clk' event AND clk='1'; output_signal <= 0; while (input_signal < 6) loop wait until clk' event AND clk='1'; output_signal <= output_signal +1; end loop; end process; > What is so hard about replacing "/" by a division circuit? Especially > for a tool that is > delivered with a core generator that supports division? Especially for > division by a constant (can be implemented by a multiplier, yet > multiplication is supported)? I agree, not sure what the reason is. > > At least most tools now recognize initialization values for signals. > Took them only 20 years to implement that. This might work for Xilinx which can initialise a register from the bitstream, however, what would happen if you use this design on a ASIC or FPGA that doesn't support this (e.g. Actel). I am all in favour of technology independent code and inferring as much as possible, makes life so much easier for the next guy to pick up your code :-) Hans www.ht-lab.com > > > My frustration comes from work in the EDA software field. I see that > really hard tasks that are solved successfully during the synthesis > and implementation process and wonder why topics like those above or > not handled well, even though they are a lot simpler. > > Kolja Sulimma > > > > > >Article: 123426
Hi, I was wondering if anyone has implemented the XHWIF interface for any Virtex II device in other words the C/C++ dlls required to make the interface work I was planning write the source on my own since Xilinx hasn't provided any examples that can be referenced and I couldn't find anything of help on the web either. If anyone has already implemented it though it would really help. I am using Avnet's Virtex-II Evaluation Kit with a XC2V1000-4FG256 thanks, ShadabArticle: 123427
Hi, I am confused about the clocking scheme of the two most popular hdl. The most common usage of clock and reset signal is clk'event clk=3D1 or reset=3D1. As you see reset signal seem to be a level sensitive as it should be. But in verilog the common structure for clocking is posedge clk or negedge reset. As you see there is an edge constraint for reset signal in verilog. Why this is different in these hdls. Does this have any importance from the technology point of view ? I mean if the synthesized circuits are same or different by the same synthesis tool. An=FDl =C7ELEB=DDArticle: 123428
On Tue, 28 Aug 2007 01:40:22 -0700, anilcelebi@gmail.com wrote:
>Hi,
>
>I am confused about the clocking scheme of the two most popular hdl.
>The most common usage of clock and reset signal is clk'event clk=1 or
>reset=1.
I hope you are now using the much clearer form
rising_edge(clock)
but yes, you're right.
>As you see reset signal seem to be a level sensitive as it
>should be. But in verilog the common structure for clocking is posedge
>clk or negedge reset. As you see there is an edge constraint for reset
>signal in verilog. Why this is different in these hdls.
Because Verilog cannot detect the clock edge in procedural code.
Many people are surprised to see the edge specification on reset
in Verilog. However, think what would happen without it....
always @((posedge clock) or reset) /// WRONG
if (reset == 1'b0)
Q <= 0;
else
Q <= D;
Imagine that clock is frozen at 0. Now make reset go from
1 to 0: this is good, the edge on reset triggers the always
block, (reset==1'b0) is true, the flip-flop resets. Next,
take reset away (0->1). The rising edge on reset will
again trigger the always block. (reset==1'b0) is now false.
Consequently, the clocked action Q<=D is executed. This is
clearly wrong.
> Does this have
>any importance from the technology point of view ? I mean if the
>synthesized circuits are same or different by the same synthesis tool.
No. Synthesis treats the standard clocked templates in the same
way for Verilog and VHDL.
The one big difference is that it is effectively impossible to
use this style in Verilog to describe a flip-flop that has BOTH
asynchronous set AND asynchronous reset, whereas in VHDL it's
easy. In practice, though, this isn't a significant problem.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 123429On 28 Aug., 10:27, "HT-Lab" <han...@ht-lab.com> wrote: > "comp.arch.fpga" <ksuli...@googlemail.com> wrote in message > > At least most tools now recognize initialization values for signals. > > Took them only 20 years to implement that. > > This might work for Xilinx which can initialise a register from the > bitstream, however, what would happen if you use this design on a ASIC or > FPGA that doesn't support this (e.g. Actel). I am all in favour of > technology independent code and inferring as much as possible, makes life so > much easier for the next guy to pick up your code :-) I believe that's similar to instantiating 10 millon gates in a device that only supports 5 million gates or stating a 500MHz constraint when only 250 are possible. The tool should tell you the reason why it can't be done. Excludig a feature because a small portion of technologies can't support it is not wise. Especially in a case like the reset values were you get a simulation mismatch because of the omission. Kolja SulimmaArticle: 123430
On 2007-08-27, Mike Treseler <mike_treseler@comcast.net> wrote: |------------------------------------------------------------------------| |"[..] | | | |> I have two questions: | |> 1. Based on my experiences with VHDL, the following 3 designs should | |> be the same. | | | |Yes. [..] | | | |[..]" | |------------------------------------------------------------------------| I disagree. A2 is equivalent to A3. A1 and A2 could be equivalent, but not necessarily. In A1, State_A has the value State_0_S and is assigned the value it already has. Instead of that assignment, A2 has a null statement. However, A1 is not necessarily equivalent to A2 if: A2 could be running with another process which is assigning any other value to State_A; or the assignment State_A <= State_0_S; could delete previously computed transactions from the projected output waveform. Regards, Colin Paul GlosterArticle: 123431
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message
news:1188263507.145095.110420@q3g2000prf.googlegroups.com...
> It has two mutually exclusive signal groups: signals E0, E1 and E2 are
> mutually exclusive. So are signals E3, E4 and E5.
>
> The implementation benefits with FPGA are huge !!!
>
> For example:
>
> OutBus has 64-bit width.
>
> OutBusA : process(RESET, CLK)
> begin
> if(RESET = '1') then
> OutBus <= (others=>'0');
> elsif(CLK'event and CLK = '1') then
> If(E0 = '1') then
> OutBus <= Data0;
> orif(E1 = '1') then
> OutBus <= Data1;
> orif(E2 = '1') then
> OutBus <= Data2;
> orif(E3 = '1') then
> OutBus <= Data3;
> orif(E4 = '1') then
> OutBus <= Data4;
> orif(E5 = '1') then
> OutBus <= Data5;
> end if;
> end if
> end process;
>
Hi,
I don't want to get involved in a language crusade, and I don't like to
crosspost so you'll need to read this on CAF, but why not just do something
like this? :-
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
OutBus1 <= (others=>'0');
OutBus2 <= (others=>'0');
OutBus3 <= (others=>'0');
OutBus4 <= (others=>'0');
OutBus5 <= (others=>'0');
elsif rising_edge(CLK) then
if (E1 = '1') then OutBus1 <= Data1; else OutBus1 <= (others=>'0'); end
if;
if (E2 = '1') then OutBus2 <= Data2; else OutBus2 <= (others=>'0'); end
if;
if (E3 = '1') then OutBus3 <= Data3; else OutBus3 <= (others=>'0'); end
if;
if (E4 = '1') then OutBus4 <= Data4; else OutBus4 <= (others=>'0'); end
if;
if (E5 = '1') then OutBus5 <= Data5; else OutBus5 <= (others=>'0'); end
if;
OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5;
end if
end process;
Google comp.arch.fpga for a thread subject :-
Multidimensional Register in Modul Port List
and read Mr. Bromley's posts.
HTH., Syms.
Article: 123432I am registering a data bus at the input of a Xilinx Virtex FPGA (XCV300) using IOB registers. It appears that some of the register bits are locking in incorrect data. All registered bits are brought back out of the device for debug purposes. When looking at logic analyzer waveforms, it appears that the data bus coming in is stable, yet a few bits inside the FPGA are registered incorrectly. We have tried to adjust the signal level of the logic analyzer to look for glitches on the input data bus but do not find any. All we can figure is that there must be some ringing or transmission line effects on the data bus. Are the Xilinx IOB registers particularly sensitive to noise? What other effects could lead to registering the incorrect value? It appears that the setup time for the data bus is approximately 7.5 ns, so that is much greater than the Xilinx spec of 2.1 ns setup. ANy thoughts would be appreciated.Article: 123433
On Tue, 28 Aug 2007 01:11:47 -0000, Weng Tianxiang <wtxwtx@gmail.com> wrote: >I open a new topics from previous one to try to stir another round to >introduce a new keyword 'orif'. Weng, It seems to me that what you are trying to do is very similar to SystemVerilog's "unique" and "priority" keywords. It is not completely clear from your posts exactly what the semantics of "orif" should be, but as I understand it you intend that "orif" should have exactly the same behaviour as "elsif", together with a mutual-exclusivity check so that it is an error if more than one of the "if" conditions is true. I agree that this is a desirable thing to be able to say. I do not fully understand how your combinations of "orif" and "elsif" are intended to work. It is also desirable to be able to specify that *at least* one of the conditions is true. And then you can combine the "at-least-one" and "at-most-one" tests to guarantee that there is EXACTLY one condition true. Note that SystemVerilog got this wrong, in my opinion: "unique" enforces exactly-one, and "priority" enforces at-least-one, so there is no easy way to specify at-most-one. It is easier in VHDL than Verilog, because the test expressions cannot have side-effects. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 123434
Weng Tianxiang <wtxwtx@gmail.com> writes:
[lots of stuff]
What you are looking for seems to be more or less equivalent to
SystemVerilog's `unique if' statement. It could have been written
using a case statement instead but I was trying to stay close to the
proposed VHDL syntax.
Synthesis and formal tools *may* use that information. Simulation
gives you a run-time error in case of a violation.
,----
| 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
`----
Regards,
Marcus
--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]
(seen on http://www.veripool.com/verilog-mode_news.html)
Article: 123435
Hello again,
After giving some thought about this issue, I'd like to show my own
solution (i.e. answer my own question).
But before that, my opinion about multicycles: I'm generally in favor
of using clock enables instead of multiple clocks whenever possible.
The worst thing about being generous with clocks is that each core has
its own set of clocks, and before you know it, you're out of clock
resources.
Personally, I try to keep my HDL reusable, which generally means to
use device-dependent resources as little as possible. For example, I
don't know of a portable way to make a pipelined multiplier (I know,
of course, how to do that with Coregen).
So to summarize my opinion, I do prefer a single clock, with clock
enables within the core, in order to make it easier to reuse. And this
brings up the need for a reliable way to define multi-cycle paths.
----------------------
Now to my suggestion: The problem is that paths which end up in the
flip-flops' CE pin are taken for multi-cycle paths. After all, the CE
is sampled by the flip-flop on every clock. So let's exclude exactly
those paths.
With the example I gave in the beginning, let's change the UCF to:
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";
The first four lines are like before (except I've corrected "tgrp_en"
to include flip-flops only).
And then comes the fix: The two rows next pick all paths which start
at multi-cycled flip-flops, but end at CE pins. These paths are
returned to their original, single-cycle timing.
So what we have now is this: If a path begins at a flip-flop which
changes value every 4 clocks, and ends at a flip-flop which samples at
the same clock enable, that path can take longer. This statement is
now true, because we've excluded paths that end on the CE pin, which
is sampled on every clock.
Note that if the relevant paths are crossing clock domains or are used
against flip-flops which sample on reverse edge of the clock, we might
mess things up. So I would suggest using a more specific definition
for "tgrp_ces" ("*.CE" is just for the example).
Does anyone see a problem with this?
By the way, I *was* somewhat worried that the timing calculation would
change. It wasn't clear to me if referring to the flip-flop's CE pin
in the TPSYNC constraint rather than using the INST/TNM pair for the
entire flip-flop, would change the timing endpoint, resulting in a
different timing calculation. But it turns out that the tools include
Tceck (CE to clock) in both cases, which results in identical
calculations (at least where I managed to compare them).
So what do you say about this?
Eli
Article: 123436On Aug 27, 6:25 pm, MikeShepherd...@btinternet.com wrote: > Is there a text version? > > I've never understood the logic of listening to someone drone on in a > thick foreign accent when the same person could just publish the text > or write a web article that we can all read much faster. > Definitely with you on this one! I don't even have speakers connectd to my soundcard. Webcasts to me usually look like a _VERY_ slowly moving powerpoint slide set, possibly with a talking head in the corner of the screen. Where there have been text downloads, they are usually a direct transcript of the talking head, complete with umms, errrs, etc. Once again I think the point of webcasts is to force registration to see who is listening, while avoiding the extra pain of making a readable informative document. (See recent thread "Annoying"). Just my 2 cents Gabor > Don't engineers read any more? > > >Lattice is holding a webcast this Wednesday, August 29th, "Tips to > >Avoid Simultaneous Switching Output (SSO) Noise Problems." The > >presenters will be Troy Scott, from our software marketing group and > >Bertrand Leigh, from our applications engineering group. > > >If you're interested, the event takes place live at 11am Pacific, > >18:00 GMT. In addition, you will be able to view this webcast archive > >on-demand, at your convenience, within 24 hours after the live event > >takes place. > > >You can register by clicking: > >http://www.latticesemi.com/corporate/webcasts/tipstoavoidsimultaneous... > > >Bart Borosky, LatticeArticle: 123437
On Aug 27, 7:38 pm, austin <aus...@xilinx.com> wrote: > Sanjay, > > I suggest you use the power estimator spreadsheet to answer your question. > > You did not say if you were asking about Xilinx, or someone else. You > will find the V5 power estimator here: > > http://www.xilinx.com/ise/power_tools/license_virtex5.htm > > Austin Either way, I suspect the input frequency has less to do with power consumption than the VCO frequency. The latter is generally only a function of the output divisor.Article: 123438
> Is there a way I can read in a text / ascii /binary file AFTER P&R is > done to mimic a ROM ? > > I could use block-RAM instead of ROM to read in this file. Yeah, there is no ROM in your FPGA, so the tools will synthetize it using either BRAM or LUTs depending on how many bytes you want. You can also instantiate a BRAM directly. In XPS, when you use BRAMs connected to LMB or OPB bus, the xilinx tools are able to write data to the BRAM in the bitstream (ELF executables for instance). In this case an address map is generated which tells the data2mem tool which physical BRAM corresponds to which address. I do not know how it would work for a direct BRAM instantiation, but you can probably use the same tools (platgen / data2mem) to get what you want with a bit of hacking.Article: 123439
On Aug 28, 4:54 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Tue, 28 Aug 2007 01:40:22 -0700, anilcel...@gmail.com wrote: > >Hi, > > >I am confused about the clocking scheme of the two most popular hdl. > >The most common usage of clock and reset signal is clk'event clk=1 or > >reset=1. > > I hope you are now using the much clearer form > rising_edge(clock) > but yes, you're right. > > >As you see reset signal seem to be a level sensitive as it > >should be. But in verilog the common structure for clocking is posedge > >clk or negedge reset. As you see there is an edge constraint for reset > >signal in verilog. Why this is different in these hdls. > > Because Verilog cannot detect the clock edge in procedural code. > > Many people are surprised to see the edge specification on reset > in Verilog. However, think what would happen without it.... > > always @((posedge clock) or reset) /// WRONG > if (reset == 1'b0) > Q <= 0; > else > Q <= D; > > Imagine that clock is frozen at 0. Now make reset go from > 1 to 0: this is good, the edge on reset triggers the always > block, (reset==1'b0) is true, the flip-flop resets. Next, > take reset away (0->1). The rising edge on reset will > again trigger the always block. (reset==1'b0) is now false. > Consequently, the clocked action Q<=D is executed. This is > clearly wrong. > The big difference between the Verilog and VHDL template is the lack of an "if" along with the "else". In the case of clock frozen at 0, you might be able to fix this using else if (clock) but then you'd have bad behavior in the clock frozen high case. In non-synthesizable code you could add @(posedge clock) in the else clause, but that would require waiting for an additional clock edge when the always block is triggered by the rising edge of clock. > > Does this have > >any importance from the technology point of view ? I mean if the > >synthesized circuits are same or different by the same synthesis tool. > > No. Synthesis treats the standard clocked templates in the same > way for Verilog and VHDL. > > The one big difference is that it is effectively impossible to > use this style in Verilog to describe a flip-flop that has BOTH > asynchronous set AND asynchronous reset, whereas in VHDL it's > easy. In practice, though, this isn't a significant problem. What about? always @(posedge clock or negedge reset_n or negedge set_n) if (!reset_n) Q <= 0; else if (!set_n) Q <= 1; else Q <= D; > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated.Article: 123440
Analog_Guy wrote: > I am registering a data bus at the input of a Xilinx Virtex FPGA > (XCV300) using IOB registers. It appears that some of the register > bits are locking in incorrect data. > > All registered bits are brought back out of the device for debug > purposes. When looking at logic analyzer waveforms, it appears that > the data bus coming in is stable, yet a few bits inside the FPGA are > registered incorrectly. We have tried to adjust the signal level of > the logic analyzer to look for glitches on the input data bus but do > not find any. > > All we can figure is that there must be some ringing or transmission > line effects on the data bus. Are the Xilinx IOB registers > particularly sensitive to noise? What other effects could lead to > registering the incorrect value? It appears that the setup time for > the data bus is approximately 7.5 ns, so that is much greater than the > Xilinx spec of 2.1 ns setup. > > ANy thoughts would be appreciated. Check the timing of your clock relative to your data on the FPGA and check your Timing Analyzer "Data Sheet" section for the setup and hold times. Are they compatible? I'd bet that your problem isn't noise but a matter of missing the clock cycle and getting the bit before or after the cycle you expect (or not at all depending on how you're sampling your data). - John_HArticle: 123441
On Aug 28, 7:07 am, Analog_Guy <analog_...@hotmail.com> wrote: > I am registering a data bus at the input of a Xilinx Virtex FPGA > (XCV300) using IOB registers. It appears that some of the register > bits are locking in incorrect data. > > All registered bits are brought back out of the device for debug > purposes. When looking at logic analyzer waveforms, it appears that > the data bus coming in is stable, yet a few bits inside the FPGA are > registered incorrectly. We have tried to adjust the signal level of > the logic analyzer to look for glitches on the input data bus but do > not find any. > If you suspect ringing or glitches I'd look with a scope instead of the logic analyzer. When you say the bus is stable, do you mean a bit that hasn't changed state is registered at the opposite state? > All we can figure is that there must be some ringing or transmission > line effects on the data bus. Are the Xilinx IOB registers > particularly sensitive to noise? What other effects could lead to > registering the incorrect value? It appears that the setup time for > the data bus is approximately 7.5 ns, so that is much greater than the > Xilinx spec of 2.1 ns setup. > What about hold time? Are the input registers using the built-in delay path? What does the post P&R timing report show for hold time requirement on these inputs? > ANy thoughts would be appreciated. All Virtex registers are fast in terms of capturing glitches. Another thing to look at with a scope is the rise / fall time of the input signal. Logic analyzers tend to mask this. Maybe you don't have as much setup time as you think if the Virtex and logic analyzer don't use the same threshold levels. HTH, GaborArticle: 123442
On Tue, 28 Aug 2007 06:00:09 -0700,
Gabor <gabor@alacron.com> wrote:
>On Aug 28, 4:54 am, Jonathan Bromley wrote:
>> [...] it is effectively impossible to
>> use this style in Verilog to describe a flip-flop that has BOTH
>> asynchronous set AND asynchronous reset, whereas in VHDL it's
>> easy. In practice, though, this isn't a significant problem.
>
>What about?
>
>always @(posedge clock or negedge reset_n or negedge set_n)
>if (!reset_n)
> Q <= 0;
>else if (!set_n)
> Q <= 1;
>else
> Q <= D;
No, that doesn't work correctly. Consider what happens
if both reset_n and set_n are asserted (low) - then, of
course, Q has been driven to 0. Now imagine that the
high priority asynch signal, reset_n, is released
back to 1. The always block does NOT trigger.
Consequently, the asynchronous set - which should then
take over, since it is still asserted - has no effect.
You can fix that for simulation by hacking the sensitivity
list:
always @(posedge clock or negedge reset_n or
negedge (set_n || (!reset_n)) )...
but synthesis tools won't accept that because they won't
accept any expression in a neg/posedge.
It's a mess. Worse still, some synthesis tools accept
the style you suggested and infer asynch set and reset
from it, immediately generating a simulation/synthesis
mismatch.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 123443Hi I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a general rule of how many layers the pcb will need to route out all the pins? Cheers JonArticle: 123444
Hello Sanjay, Our experience is that the PLL's power consumption is fairly low as compared to the clock network it is driving in most cases. To get a sense for the amount of power the PLL consumes as a function of the VCO frequency, download a copy of the Early Power Estimator spreadsheet for the device you are interested in (http:// www.altera.com/support/devices/estimator/pow-powerplay.jsp). For a more detailed analysis, grab a copy of Quartus and fire up a toy design with the PLL in it, and run it through the PowerPlay Power Analyser. The PLL models for 90 nm and 65 nm devices take into account your VCO frequency, M/N values, and counter settings. Regards, Paul Leventis Altera Corp.Article: 123445
On Aug 28, 9:23 am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a > general rule of how many layers the pcb will need to route out all the > pins? > > Cheers > > Jon In the Virtex 2 users guide there are suggested breakout routings for each package. There should be similar documentation for V4. Note that your layer count will depend on the design rules you choose for pcb manufacture. At 1mm spacing, you may need to reduce your via drill size to 10 mils (gotta love mixed units of measure) and leave out unused pads on inner layers to allow more routes between adjacent pads. With 5 mil width and spacing and 12/25 mil via drill/pad you can only run 1 line between pads. We've made boards using similar dense packages using from 8 to 12 layers depending on design rules. For at least the suppliers we use, saving layer count reduces price significantly even if you need to use fine (10 mil) drills. Suggested breakout patterns also require dogbone removal on the outer two rings of pads. Be sure to run unconnected outer pads to a test point since you won't be able to access them without the dogbone / via. After you look at the breakout drawings, don't forget to add the appropriate number of plane layers to deliver all of your supply voltages. You may need more than 1 ground plane depending on your I/O switching rates. Good Luck, GaborArticle: 123446
maxascent wrote: > Thanks for all the advice. My link will be running at 3.25Gbps. I think > that I am going to use one of the santec board to board 50 ohmn > connectors. > > Jon One hint: you could also look at PCI-Express connectors and pinout as a reference. On PCIe, the pinout looks a lot like this: Front ....... G G D1+ D1- G G D3+ D3- G ... Back ... G D0+ D0- G G D2+ D2- G G ....... Each differential pair is effectively surrounded by ground pins on all practically possible sides. Since PCIe 2.0 will use the same connectors (or slightly improved ones) to run at 4Gbps, these should be suitable for quite a bit more than 3.25Gbps if trace pairs are kept short and routed properly.Article: 123447
Thank you for your responses. On Aug 28, 9:07 am, Gabor <ga...@alacron.com> wrote: > > If you suspect ringing or glitches I'd look with a scope instead > of the logic analyzer. When you say the bus is stable, do you mean > a bit that hasn't changed state is registered at the opposite state? > I will have to get a scope, but for the time being ... the data bus coming in does not change state, yet some bits are registered at the opposite state for 1 clock cycle (@ 60 MHz). > What about hold time? Are the input registers using the built-in > delay path? What does the post P&R timing report show for hold > time requirement on these inputs? The data sheet report shows that the setup times for all data bus bits are 1.958 ns, and the hold times are -1.006 ns. > > All Virtex registers are fast in terms of capturing glitches. Another > thing to look at with a scope is the rise / fall time of the input > signal. Logic analyzers tend to mask this. Maybe you don't have > as much setup time as you think if the Virtex and logic analyzer > don't use the same threshold levels. > > HTH, > Gabor I will have to instrument a scope to look at the rise times ... thank you.Article: 123448
fpgabuilder wrote: >>>> - IFDDRxxx and OFDDRxxx components implement output and input logic >>> Yes, These are very necessary. Clock the signals as close to the IO >>> pin as possible. The setup and hold times will vary more as the amount >>> of logic increases which is something you don't want. >>>> - Digitally Controlled Impedance (DCI) - but require some pins: VREN, >>>> VREP >>> Useless. It will make the chip run very hot especially with many lines >>> connected. Use series resistors on the board. >> Agreed, but DDR should have a known impedance at the driver and >> receiver, which I believe the SSTL (II) IO standard provides. >> > I recently removed the series and parallel terminations from a Cyclone > 3 dev board and ran the ddr interface at 133MHz. The interface worked > overnight without a problem. > > I think the trace length on the ddr signals is about 2-3 inches. They > are point-to-point signals. The data bus is 16bits wide and is > implemented using Altera's ALTMEMPHY megafunction. Further, I > momentarily cooled down the memory and altera chips to -40degC and > then heated them up to 125degC without any errors. > > I see that without the series terminations there is a problem on the > overshoot and undershoot. But it does not violate the specs of the > fpga. On the memory side, the problem goes away when I use onchip > series termination. When trace lengths are below 1/100 of your clock's electrical wavelength, you can get away with lots of otherwise potentially nasty stuff. To reduce your overshoot, you could also experiment with programmable drive strengths from both FPGA and DRAM ends.Article: 123449
I apologize if almost the same response as this is received. I had typed a response which I thought I posted over an hour ago but it does not seem to appear even on the server I originally had posted it on, so I retype a response and I try a different client and server. In news:1188287118.863429.148200@o80g2000hse.googlegroups.com timestamped Tue, 28 Aug 2007 07:45:18 -0000, "comp.arch.fpga" <ksulimma@googlemail.com> posted: |----------------------------------------------------------------------------| |"[..] | | | |At least most tools now recognize initialization values for signals." | |----------------------------------------------------------------------------| Synopsys Presto VHDL does not, according to what is documented on Page C-5 of sold/doc/online/dc/pvhdl/pvhdl_c.pdf for Version Y-2006.06. Which synthesis tools do support initialization of signals? |----------------------------------------------------------------------------| |"Took them only 20 years to implement that. | | | | | |My frustration comes from work in the EDA software field. I see that | |really hard tasks that are solved successfully during the synthesis | |and implementation process and wonder why topics like those above or | |not handled well, even though they are a lot simpler. | | | |Kolja Sulimma" | |----------------------------------------------------------------------------| Perhaps because they are too lazy to implement features which customers can easily be led to believe are frills? E.g. Jonathan Bromley posted on 2007 March 5th: "[..] [..] The majority of hardware platforms do not offer reliable power-up initialisation of internal state. Consequently it is appropriate to code explicitly some reset behaviour. For exactly this reason, the hardware-oriented data types in VHDL (std_logic, etc) have a specific undefined value as the leftmost value of their value-set, so that initialisation oversights are more likely to be detected. Unfortunately for a purist such as you, there are many occasions in hardware design where it is entirely appropriate to read an uninitialised object. For example, a pipeline or shift register probably does not need the hardware overhead of reset; it will automatically flush itself out over the first few clock cycles - but only if you allow it to run, which of course entails reading uninitialised (or default-initialised) values. Consequently it is appropriate for synthesis tools to do pretty much what they generally do: don't worry about initialisations. For preference, they should issue warnings about attempts to do explicit initialisation, since these cannot be synthesised to hardware on most platforms. However, even then it may be appropriate to let this past, since the explicit initialisation may be useful in order to limit the excessive pessimism that usually occurs when a simulator is confronted with a lot of 'U' or 'X' values. This issue is one of those things that hardware designers are required to be aware of, and failure to attend to it is usually a good identifying mark of a beginner, or a dyed-in-the-wool programmer assuming that hardware design is easy. [..]" Regards, Colin Paul Gloster
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