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
On Sep 4, 6:54 pm, NickNitro <NickHo...@googlemail.com> wrote: > Hi all, > > >>Perhaps in theory, but 'algortihm development' is a very fluid thing, and a good designer allows for late changes. > > Well I don't think I've mentioned just how far the algorithm is > through development, although is it completely designed and has been > finalised by many people and all have signed it off. It has been > designed down to the bit level and has been tested in a software > environment with no flaws (strong words, but every possible scenario > has been tested through brute forcing, so nothing has been missed); so > I can safely say the algorithm being altered at this stage won't > happen. > > >>Device retargeting is not difficult. > > I've done what you've suggested and had a look at the Xilinx web pack > and if I've done it correctly, device retargeting seems to be just be > selecting a different device from the list? Or am I greatly > oversimplifying to what I imagine? > > >>Don't you ever get a new idea after a design has been running for a while? > > Very much, although as above, the algorithm is set in concrete. > > >>Why would you think that way? Getting on/off chip is usually slow. > > Naivety. ;) I'm coming from a software background, so unfortunately > I'm relying on software knowledge, where more cores==better > performance. > > >>CPLDs generally have wide inputs relative to LUTs in FPGAs. There are probably some designs that will be faster on CPLDs because they take advantage of that. > > I'm afraid I don't have a clue what 'wide inputs' are, but I'll take > your word at it. ;) > > >>even if you have to operate sequentially on 128000 bits > > Yes, that's correct. > > >>I would also use one of the many existing evaluation boards, which eliminates a lot of work, time, money, and risk. > > Thing is, once it's working fine in the FPGA/evaluation board > environment, I'll still need to move the chip to a custom PCB so it > has the correct peripherals? > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - > > Speed is extremley important to this problem, I'm not too worried > about the difficulty of this - just the final result; since ideally > execution of the algorithm cannot take more than 15-20 milliseconds. I > hope you don't think I'm being completely ignorant and rude asking > this, nor do I want you to think that I don't appreciate your advice - > although I can't help but think something like the following would be > faster - I'm stuggling to shake off my software thinking: > > http://img529.imageshack.us/img529/9474/cpldlayoutus9.jpg > Nick, you can implement the same (or many other) structure(s) in an FPGA. You have many hundreds of I/O pins, wide adders and multipliers (if you need them) and tens of thousands of flip-flops (rather scare resources in CPLDs). You can have many (hundreds) of independent or dependent operations going on in the FPGA simultaneously. Don't forget pipelining to enhance throughput by using many of the "free" flip- flops... But you have to make the decision that you are comfortable with. Regarding peripherals, you can get them "for free", i.e. without design effort, in the more sophisticated development boards, like the Xilinx ML405. That allows you to concentrate on the uniqueness of your design, and avoid pc-board lay-out, manufacturing and debugging headaches, for just a few hundred dollars or pounds in your case Peter Alfke (we are all just trying to preserve your good spirits and your sanity) > Where 32 bits would be passed from a 'CPLD Memory Manager' to a 'CPLD > Parallel Algorithm', and while that was working, another 32 bits would > be passed from the same 'CPLD Memory Manager' to the next 'CPLD > Parallel Algorithm', etc... and each 'CPLD Parallel Algorithm' when > complete would check that the other 'CPLD Memory Manager' was > available to take data and if so pass it to the memory manager, and > then asking the first memory manager for some more data. > > Again, I apologise for sounding like a broken record. I'd appreciate > your thoughts for the pros and cons for something like this. > > Thanks, > Nick.Article: 123801
On Tue, 04 Sep 2007 19:45:10 -0000, vasile <piclist9@gmail.com> wrote: >On Sep 1, 7:44 am, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Thu, 30 Aug 2007 15:36:04 +0100, "Symon" <symon_bre...@hotmail.com> >> wrote: >> >> >> >> >> >> >"maxascent" <maxasc...@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. >> >> That's not necessary. There's already so much plane-plane capacitance >> that the planes are already equipotential as far as the tiny charge >> injected by the signal trace can affect them. >> >> Really, on a board with, say, 3000 vias, are you going to put a bypass >> via near every signal via? I've heard of people asking for two! > >If you're routing a long 3Gbps differential signal, then definitely >you must have ground vias near every signal pair vias. Why? If the signal is balanced, it needs even fewer vias than a single-ended signal, which needs none. JohnArticle: 123802
@Kunal I do synchronisation with the async. signal. Therefore I have to wait at least two clock cycles after the falling edge of the read strobe. That is the delay that comes with the synchronisation. So I added two wait states in the FSM. I found also a other solution to met the timing requirement. I have to reduce the clock to output delay of the strobe signal. That can be achieved by putting the output d-Flip Flop in the IOB. At the moment the solution with the synchronisation works.Article: 123803
On Tue, 04 Sep 2007 11:08:49 -0700, NickNitro <NickHolby@googlemail.com> wrote: <...> >Hi, >Finally, could >anybody recommend any books for getting started in the CPLD world - >I'm unsure to use Verilog or VHDL at the moment? > Take a llok at: HDL Programming fundamentals, Nazih M. Botros, Da Vinci Enginnering press. It is a simultaneous introduction to VHLD and Verilog, so you may compare pros and cons of both languages easily. Try both in some FPGA design tool, and decide for yourself. Best regards, ZaraArticle: 123804
hi
I am designing a generic arbiter .
while synthesis the xilinx tool is giving warning
WARNING:Xst:646 - Signal <inter> is assigned but never used.
WARNING:Xst:1780 - Signal <k> is never used or assigned.
I searched it out in the solution record
warning 646 can be ignored .
but warning 1780 is displayed in the case of jtag ,so i am not able to
conceive why this is coming.
i have pasted the design below.
thanks for help
ankur
module pri_encoder32(inbus,outbus);
parameter size=9;
parameter size_1=size-1;
parameter size_out=4;
input [size-1:0]inbus;
output reg [size_out-1:0]outbus;
reg [size_out-1:0]k;
reg [size_out-1:0]inter;
always @(inbus)
begin
inter=0;
for (k = size; k >= 1; k = k - 1)
begin
if (inbus[k-1]==1)
begin
outbus = k-1;
inter=k-1;
end
else
begin
outbus=inter;
end
end
end
endmodule
Article: 123805Paulo Dutra wrote: > Is your moduleA and moduleB listed in the PAO file? > If is not listed in the PAO, then it will not synthesized by XST. Xst > will give a warning that the moduleA and moduleB are black box components. > > Take a looke at you <proj_directory>/synthesis/opb2ip_bridge_0_xst.srp > This is the syntesis report file for your component. Look for warnings > regarding moduleA and moduleB. > > L. Schreiber wrote: Exactly, this was the problem, I found out yesterday late afternoon, too. :-D Thanks anyway. So I don't need to write the solution anymore.Article: 123806
On Wed, 05 Sep 2007 07:47:40 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote: >NickNitro wrote: >> Hi, >> >> Apologies if this isn't the best group, but there doesn't appear to be >> a comp.arch.cpld group. >> >> I'm going to start learning about CPLDs to use them in my projects, >> but the algorithm I've developed will require a few CPLDs working on >> different parts of the algorithm in sequence. So part A of the >> algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. > >Probably not the best direction. > >> They >> are all complete guesses at the moment, as I know next to nothing >> about PLDs in general, but I know that for my algorithm to run as fast >> as required, I will require multiple PLDs. I'm choosing CPLDs as from >> what I've read FPGAs can be a bit overbearing for a beginner due to >> the amount of features/number of gates they have, > >You do not have to use all features on the first pass :) More gates means you don't need to worry about squeezing your design to fit, so you can concentrate on getting it working. You can ignore peripherals etc. you don't need, and if you start with one of the many devboards, you don't need to worry about the more complex multiple power supplies or config devices.Article: 123807
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:aq5sd3p1mttvq1s6kh9dcal265cokucd05@4ax.com... > On Tue, 04 Sep 2007 19:45:10 -0000, vasile <piclist9@gmail.com> wrote: > >> >>If you're routing a long 3Gbps differential signal, then definitely >>you must have ground vias near every signal pair vias. > > Why? If the signal is balanced, it needs even fewer vias than a > single-ended signal, which needs none. > > John > Hi John, As I'm sure you already know, this is because usually edge coupled signal pairs on a PCB are not 'proper' differential pairs the way (say) twisted pairs in CAT-5 are. The coupling between each distinct trace and the ground plane is much greater than the coupling between the pair of traces themselves. This is why Xilinx (and almost everyone else except, apparently, you) recommend this GSSG structure when passing high speed differential signals through vias. The vias reduce the common mode inductance of the transistion, which is, after all, essentially two single ended signals. (In fact the via is much more important for a single ended signal than a differential one, as a single ended signal is all 'common mode' and the ground via significantly reduces transition inductance.) Today's hilariously bizarre link collection is here http://www.xilinx.com/bvdocs/userguides/ug076.pdf http://www.edn.com/contents/images/300022.pdf Read chapter 11 of UG076, and check out fig.11.10. BTW., I saw the link you posted to your products. Thanks, they look great. I noticed that you chose to put them all in metal boxes or racks. Bearing in mind your philosophy on SI, I think that was a wise choice. Cheers, Syms.Article: 123808
"David" <spdracer911@gmail.com> wrote in message
news:1188927341.571209.55110@g4g2000hsf.googlegroups.com...
>
>
> I have a design that uses a 100Mhz system clock, but only a very small
> portion actually runs at 100MHz. The rest of the FFs in the design
> use a synchronous "clk_10M_en" signal which is active for one clock
> period and repeats every 100ns. I would like to know how to specify
> the constraints correctly so that Actel Designer (i.e. SmartTime))
> knows "that paths FROM FFs using clk_10M_en TO FFs using clk_10M_en"
> are 100ns paths, not 10ns paths.
>
> It's quiet easy to add a multicycle path constraint on the two
> registers, such as:
>
> set_multicycle_path 10 -from {reg1:CLK} -to {reg2:CLK}
>
> But what I need is a solution that can find these registers when they
> are buried in a hierarchy of modules. Since they all use clk_10M_en
> as their enable, there should be a way to perform a "find" and then
> set a multicycle path constraint between each regsiter.
Hi David,
You might be able to do it in your synthesis tool (in my case Precision). In
one of my designs an FSM output stage drives the enable of some output
registers. I can then use the Precision report_connection command to list
all the CE pins this FSM output signal is connected to.
# COMMAND: report_connections -net state(4)
# ix35.out {ix5.in[0]} reg_sin(11).ce reg_sin(10).ce reg_sin(9).ce
reg_sin(8).ce reg_sin(7).ce reg_sin(6).ce reg_sin(5).ce reg_sin(4).ce
reg_sin(3).ce reg_sin(2).ce reg_sin(1).ce reg_sin(0).ce reg_cos(11).ce
reg_cos(10).ce reg_cos(9).ce reg_cos(8).ce reg_cos(7).ce reg_cos(6).ce
reg_cos(5).ce reg_cos(4).ce reg_cos(3).ce reg_cos(2).ce reg_cos(1).ce
reg_cos(0).ce
I can then use a bit of Tcl to filter this list and write out some MCP
commands
set_multicycle_path -design rtl 4 -to reg_sin(*).in
set_multicycle_path -design rtl 4 -to reg_cos(*).in
Which is then translated by Precision to an Actel flavoured technology SDC
file before invoking designer,
set_multicycle_path 4 -to { U1/reg_y10_s(9)_pbrt_0:D reg_sin(3):D
reg_sin(2):D reg_sin(4):D reg_sin(5):D reg_sin(6):D reg_sin(8):D
reg_sin(1):D reg_sin(7):D U1/reg_y10_s(10)_pbrt_0:D
U1/reg_y10_s(11)_pbrt_0:D U1/reg_b(1)_dup_1028_pbrt_0:D
U1/reg_sin_addsub12_29_modgen_add_12_Carry(1)_pbrt_0:D
U1/reg_sin_addsub12_29_modgen_add_12_pog_array(2)(4)_pbrt_0:D
U1/reg_sin_addsub12_29_modgen_add_12_pog_array(2)(8)_pbrt_0:D
U1/reg_sin_addsub12_29_modgen_add_12_pog_array(2)(8)_pbrt_0_dup_52374:D
U1/reg_sin_addsub12_29_modgen_add_12_g_array(2)(4)_pbrt_0:D
.. snip continue for another 2 pages...
You might be able to do the same using the standard SDC
get_pins()/get_nets()/get_cells/etc commands but I haven't tried it,
Hans
www.ht-lab.com
>
> I have contacted Actel but they refer me to their docs or using the
> GUI tools which does not solve my problem.
> Surely this can be done via the .sdc constraints file using some TCL
> code.
>
> TIA.
>
> David
>
Article: 123809rkruger@altera.com wrote: > For Cyclone II devices you will find user guides on alt_dq and > alt_dqs > megafunctions on the Altera web site at http://www.altera.com/literature/ug/ug_altdq_dqs.pdf. > > Note that on Cyclone III devices Altera has changed the design/ > architecture of DDR/DDR2 interfaces to use a new megafunction called > ALTMEMPHY. This new megafunction is included with all versions of the > Quartus II software including the free Quartus II Web Edition. This > function builds an autocalibrating DDR/DDR2 PHY interface (calibrates > out PVT changes) with the goal of relieving designers from much of > the > timing analysis burden associated with static interfaces and reducing > PLL resource needs for wider DDR interfaces. The calibration feature > takes advantage of new dynamic phase adjustment circuitry included in > the Cyclone III PLL. The PLL phase shift is adjusted at power up and > automatically over time to place the read capture clock in the center > of the data valid window for the memory data calibrating out changes > over process, voltage, and temperature. Cyclone III devices also add > 2 > additional output registers in the I/O cell that improve write margin > timing. > The ALTMEMPHY user guide is available at http://www.altera.com/literature/ug/ug_altmemphy.pdf. > > > ALTMEMPHY users have the choice of using the Altera high performance > (HP) controller, third party controller, or designing their own > controller. The Altera HP controller is included with Altera software > subscriptions. Performance specifications are available in the > External Memory Interfaces chapter of the Cyclone III Handbook at > http://www.altera.com/literature/hb/cyc3/cyc3_ciii51009.pdf . > > > I hope you find this helpful. Thanks for your response. It's helpful. -- PGWArticle: 123810
Hi Thank you all very much for pointer and comments -PArticle: 123811
Hi groups, is there any reason for edk 9.1 registration failure with linux (I use the same id that successfully register edk on the same dual boot vista/ ubuntu laptop ?)Article: 123812
On Wed, 5 Sep 2007 10:30:13 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:aq5sd3p1mttvq1s6kh9dcal265cokucd05@4ax.com... >> On Tue, 04 Sep 2007 19:45:10 -0000, vasile <piclist9@gmail.com> wrote: >> >>> >>>If you're routing a long 3Gbps differential signal, then definitely >>>you must have ground vias near every signal pair vias. >> >> Why? If the signal is balanced, it needs even fewer vias than a >> single-ended signal, which needs none. >> >> John >> >Hi John, > >As I'm sure you already know, this is because usually edge coupled signal >pairs on a PCB are not 'proper' differential pairs the way (say) twisted >pairs in CAT-5 are. The coupling between each distinct trace and the ground >plane is much greater than the coupling between the pair of traces >themselves. This is why Xilinx (and almost everyone else except, apparently, >you) recommend this GSSG structure when passing high speed differential >signals through vias. The vias reduce the common mode inductance of the >transistion, which is, after all, essentially two single ended signals. (In >fact the via is much more important for a single ended signal than a >differential one, as a single ended signal is all 'common mode' and the >ground via significantly reduces transition inductance.) > >Today's hilariously bizarre link collection is here >http://www.xilinx.com/bvdocs/userguides/ug076.pdf >http://www.edn.com/contents/images/300022.pdf > >Read chapter 11 of UG076, and check out fig.11.10. The GSSG structure makes sense in both those papers, not because it provides a "return current path" (which the papers, thankfully, don't say) but because it keeps the impedances of the traces constant as they burrow through the epoxy-glass, by providing uniform grounded capacitive loading. There is a difference. That sort of thing matters at tens of gbps. It wouldn't matter if the signals were slow, a couple of hundred ps risetime or something pokey like that. > >BTW., I saw the link you posted to your products. Thanks, they look great. I >noticed that you chose to put them all in metal boxes or racks. Bearing in >mind your philosophy on SI, I think that was a wise choice. The V880 receives an optical data payload, phase locks to it, and fires any mix of eight delay generators, each of which makes delays of up to 3 seconds with 1 ps resolution. On board are power supplies, a pll, a uP crunching lots of code, and high-power electrical or laser output drivers. It mounts in a VME rack adjacent to various other boards, like Pentium SBCs, on 0.8" spacing, with no shields between. Jitter at the delayed outputs, relative to the master clock of the NIF timing system, averages maybe 3 ps RMS. There are no "return current" vias anywhere, and both single-ended and differential signals are "referenced" to any plane that's convenient. JohnArticle: 123813
Ok, thanks everybody for the comments. It seems I've underrated FPGAs in comparison to CPLDS. :) Thanks again, Nick.Article: 123814
On Sep 5, 2:49 am, ankur <ankurrawat0...@gmail.com> wrote: > hi > I am designing a generic arbiter . > while synthesis the xilinx tool is giving warning > > WARNING:Xst:646 - Signal <inter> is assigned but never used. > WARNING:Xst:1780 - Signal <k> is never used or assigned. > > I searched it out in the solution record > warning 646 can be ignored . > but warning 1780 is displayed in the case of jtag ,so i am not able to > conceive why this is coming. > i have pasted the design below. > thanks for help > ankur > > module pri_encoder32(inbus,outbus); > > parameter size=9; > parameter size_1=size-1; > parameter size_out=4; > input [size-1:0]inbus; > > output reg [size_out-1:0]outbus; > > reg [size_out-1:0]k; > reg [size_out-1:0]inter; > > always @(inbus) > begin > inter=0; > for (k = size; k >= 1; k = k - 1) > begin > > if (inbus[k-1]==1) > begin > outbus = k-1; > inter=k-1; > end > else > begin > outbus=inter; > end > end > > end > > endmodule I'm not familiar with verilog, but it looks like this boils down to k=1. You may want to post this to comp.lang.verilog. -Dave PollumArticle: 123815
Hi all, I've got a FPGA design with a lot of clocks! I know this is not really good, but I've to implement a microprocessor initially designed for an ASIC. The microprocessor uses combinatorial signals to drive latchs and Flipflops. I tried to re-clock some critical signals with a faster clock but this is not very efficient.. :-( and I've trouble with this clock, ISE gives me warnings : Route:447 - CLK Net : my_clock may have excessive skew because 2 NON- CLK pins failed to route using a CLK template. ( I've this warning for a lot of others clock generated by combinatorial logics... ) My question is how can I locate the 2 NON-CLK pins ? because I've a fanout of 678 signals... and if I've to search manually, it could be very long! Is there an ISE functionality to do that ? Thanks by advance, Best regards, Michel.Article: 123816
On Sep 3, 9:28 am, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message > > news:71fnd39ctb6egc7jjloldmvn9pjnr96u4s@4ax.com... > > > On Sun, 02 Sep 2007 22:38:38 GMT, "KJ" wrote: > > >>For whatever tools that you have that meet the following two tests, did > >>you > >>open a service request? > >>- Tool claims compliance to VHDL standard > >>- Tool does not error (or at least warning) about ignoring the initial > >>value > >>assignment > > > Every synth tool I've used issues a warning or error when it ignores > > initial values. It's a tool restriction I've learnt to live with. > > If the target device does not support initial values then that would be the > correct behaviour of the tool. If the target device does support a power up > value for registers than I still say that the service request should be > opened to the supplier for non-compliance to the VHDL standard. > > > On FPGAs with well-defined config values, I work around it by > > providing an explicit asynchronous reset in the usual way and then > > tying-off that reset to "false" somewhere in the top-level wrapper > > that organises the design for the target platform. That gives me > > no additional hardware cost in the FPGAs that I've used, and it > > gives me a different, clumsier, but equally effective way to > > specify initial values. > > But that doesn't sound like a 'tool' thing, it sounds like a way to make the > code re-usable when targeted towards devices that either do or not support > power up defined values. I thought your point had to do with grumblings > about synthesis tools but it appears that it really has to do with physical > parts that do not have guaranteed power up values. > > KJ The most often confused part about reset and initial conditions (in FPGA's, where reliable initial conditions are possible), is that neither handles the transition from reset or configuration to normal operation automatically and correctly. However, an explicit reset gives the user more options to correctly implement the transition. For example, a counter is initialized/reset to zero, but on the first clock out of reset (or configuration), the counter counts down, resulting in a rollover. Unless the reset or end of configuration is synchronized to the clock, the entire contents of the counter become undefined. And this problem is not just related to counters. One-hot state machines can get into illegal states if transitions are allowed on the first clock out of reset/configuration. In the old days (before FPGA's and dirt), we used to have rules about down counters being initialized to odd values, and up counters initialized to even values, initial transitions on state machines being single bit transitions, etc. to combat this. These methods are still valid, but are much less reviewable/auditable/verifiable that correctly handling the timing relationship between the clock and the end of configuration or reset. This timing relationship can be handled by traditionally synchronizing the deassertion of reset, or by delaying the clock sufficiently after the deassertion of reset/config. The latter is applicable regardless of whether reset is explicitly coded; the former is applicable only to explicit resets. Some FPGA storage elements (e.g. RAM) do not have a reset capability, but do have an initialization (via configuration) capability. It is vital that either the clock be disabled sufficiently after configuration is complete, or that the contents of the ram are not allowed to change on the first clock after configuration is complete (assuming one clock period is long enough to guarantee that all storage elements are out of configuration). In summary, just because VHDL initial conditions are supported by a synthesis tool does not mean that all initialization problems are automatically handled by them. AndyArticle: 123817
On Sep 4, 1:42 pm, Gabor <ga...@alacron.com> wrote: > On Sep 4, 3:40 pm, vasile <picli...@gmail.com> wrote: > > > > > > > On Aug 30, 8:41 am, Gabor <ga...@alacron.com> wrote: > > > > On Aug 30, 9:41 am, Gabor <ga...@alacron.com> wrote: > > > > > 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, > > > > Gabor > > > > One other thought if your main interest is in reducing the > > > board size. Often I find that using a x32 single-data-rate > > > (143 MHz) memory can save space. If you're using a TSSOP-66 > > > package for the DDR part, the 86-pin TSSOP for the x32 SDR > > > part has the same footprint and runs from +3.3V with no > > > requirements for VREF and DQS pins on the FPGA and no > > > Vtt or 2.5V supply. > > > How looks the Vref signal inside the DDR II ? Exactly what is good > > for ? > > > thx, > > Vasile > > Not quite sure what you're asking here. I have asked how looks the Vref internal circuitry of a DDRAM II. Why you need Vref for DDRAM II and which is the Vref value related to Vtt. I didn't ask about FPGA Vref which description is quite clear to me. It seems from your answer it's about SSTLII standard only, but I'm not sure it's the complet answer. Do you have any datasheet for DDRAM II talking in detail about the Vref problem? thx, Vasile The point I was trying to > make > is that the single-data-rate parts don't need to tie up FPGA pins with > Vref and DCI. On Virtex 2 parts, you can have as many as 6 Vref pins > in one bank. If you use SSTL2 signalling instead of LVTTL you lose > the ability to use these pins as I/O. If you also decide to use DCI > you lose an additional 2 pins per bank. The DDR parts also have more > control pins (differential clock adds one pin, DQS adds one per 8 bits > of interface). So if you can live with the data rates of the single- > data-rate parts, you can avoid a lot of headaches and perhaps use > only a small number of additional pins to double the data width. > > By the way, for SSTL2 you need Vref as a precision threshold reference > at 1/2 Vddq, usually 1.25V or 1.3V depending on the speed for DDR I > parts. LVTTL allows a wide threshold tolerance, usually 0.8 to 2.0v > but generally won't work well at DDR bit rates.- Hide quoted text - > > - Show quoted text -Article: 123818
Hello, In our application we have to receive and merge several proprietary serial channels (200 MHz) over fibers, and send all the data over Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained. While generally sending this amount of data is possible over Gbit Ethernet, doing so in an embedded system isn't easy. That's because we need to send it by UDP or TCP, for which a TCP/UDP/IP stack is required (software). Since the translation of the proprietary format is certainly done in an FPGA, I tried to calculate how to implement the whole process in an FPGA. For example, I can take an Altera Stratix II GX (with a built in Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on the Nios II soft-core processor. Unfortunately, as Altera's appnote 440 shows, the maximal bandwidth attainable this way is only 15-17 MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet adapters on PCs show a maximal bandwidth of 80-90 MByte/s. However, I wouldn't like to build in a Pentium into the embedded system. Any suggestions / recommendations on how to solve the problem ? Thanks in advanceArticle: 123819
On Sep 5, 10:46 am, michel.ta...@gmail.com wrote: > Hi all, > > I've got a FPGA design with a lot of clocks! I know this is not really > good, but I've to implement a microprocessor initially designed for an > ASIC. The microprocessor uses combinatorial signals to drive latchs > and Flipflops. > > I tried to re-clock some critical signals with a faster clock but this > is not very efficient.. :-( and I've trouble with this clock, ISE > gives me warnings : > Route:447 - CLK Net : my_clock may have excessive skew because 2 NON- > CLK pins failed to route using a CLK template. ( I've this warning for > a lot of others clock generated by combinatorial logics... ) > > My question is how can I locate the 2 NON-CLK pins ? because I've a > fanout of 678 signals... and if I've to search manually, it could be > very long! Is there an ISE functionality to do that ? > > Thanks by advance, > > Best regards, Michel. You probably know the design well enough to guess where these loads are. Are you creating a gated clock somewhere? Does this clock drive an output pin? Any flip-flop in the design using the clock will "route using a CLK template", so gates (LUTs) and pins (IOBs) and possibly clock muxes (BUFGMUX) or DCM's will be the problem loads. By the way, skew is only a problem if the loads mentioned actually drive some synchronous logic. For example gated clocks used by flip-flops receiving inputs from the original clock domain. The "excessive skew" doesn't apply to the other 676 clock loads tha do "route using a CLK template." HTH, GaborArticle: 123820
> >It is more a dirty hack to trick the tools in the desired behaviour > >than it is an effective way to specify initial values. > >Any tool is free to break your implentation and will still be in > >compliance with the language spec. > > Guilty as charged. There's no doubt that synthesis > support for initialization values - with, of course, > checks that it been applied only to variables or > signals that represent a flip-flop - would be the > best solution by far. Why the restriction on variables/signals that represent flops? It seems to me that initialization of a combinatorial variable or signal would be correctly simulated and synthesized even if it were just ignored (thus no warning issued), unless a combinatorial loop/latch were involved, which would be its own warning. Besides, variables, in and of themselves, represent neither register nor combinatorial values. References to them do. In fact, different references to the same variable can represent both a combinatorial and a registered value. That's one of their attributes which makes them so powerful. But that's another topic... AndyArticle: 123821
On Wed, 05 Sep 2007 14:59:30 +0000, eliben wrote: > Hello, > > In our application we have to receive and merge several proprietary > serial channels (200 MHz) over fibers, and send all the data over > Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained. > > While generally sending this amount of data is possible over Gbit > Ethernet, doing so in an embedded system isn't easy. That's because we > need to send it by UDP or TCP, for which a TCP/UDP/IP stack is > required (software). > > Since the translation of the proprietary format is certainly done in > an FPGA, I tried to calculate how to implement the whole process in an > FPGA. For example, I can take an Altera Stratix II GX (with a built in > Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on > the Nios II soft-core processor. Unfortunately, as Altera's appnote > 440 shows, the maximal bandwidth attainable this way is only 15-17 > MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet > adapters on PCs show a maximal bandwidth of 80-90 MByte/s. > > However, I wouldn't like to build in a Pentium into the embedded > system. Any suggestions / recommendations on how to solve the > problem ? > > Thanks in advance My first choice would be some other, more embeddable, processor running off to the side. A PowerPC from Freescale, or an ARM processor from just about anybody, comes to mind. I suspect that even a modest such processor would get some pretty high speeds if that's all it was doing. You may have to bite the bullet and write your own stack that's shared between a processor and the FPGA. I know practically nothing about TCP/IP, but I'm willing to bet that once you've signed up to writing or modifying your own stack there are some obvious things to put into the FPGA to speed things up. Slapping a big, limited temperature range, power hungry Pentium into an embedded product would not be my first choice either. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.htmlArticle: 123822
On Sep 5, 10:59 am, eliben <eli...@gmail.com> wrote: > Hello, > > In our application we have to receive and merge several proprietary > serial channels (200 MHz) over fibers, and send all the data over > Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained. > > While generally sending this amount of data is possible over Gbit > Ethernet, doing so in an embedded system isn't easy. That's because we > need to send it by UDP or TCP, for which a TCP/UDP/IP stack is > required (software). > > Since the translation of the proprietary format is certainly done in > an FPGA, I tried to calculate how to implement the whole process in an > FPGA. For example, I can take an Altera Stratix II GX (with a built in > Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on > the Nios II soft-core processor. Unfortunately, as Altera's appnote > 440 shows, the maximal bandwidth attainable this way is only 15-17 > MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet > adapters on PCs show a maximal bandwidth of 80-90 MByte/s. > > However, I wouldn't like to build in a Pentium into the embedded > system. Any suggestions / recommendations on how to solve the > problem ? > > Thanks in advance Check out Stretch http://www.stretchinc.com They have processors with 4 gigabit ethernet ports and a hardware-assisted stack that can keep up at full gigE bandwidth on at least 3 at the same time. Getting data into the Stretch processor memory can be via the "coprocessor bus" interface or by using one of the MAC interfaces as a simple FIFO.Article: 123823
On Sep 5, 9:59 am, eliben <eli...@gmail.com> wrote: > Hello, > > In our application we have to receive and merge several proprietary > serial channels (200 MHz) over fibers, and send all the data over > Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained. > > While generally sending this amount of data is possible over Gbit > Ethernet, doing so in an embedded system isn't easy. That's because we > need to send it by UDP or TCP, for which a TCP/UDP/IP stack is > required (software). > > Since the translation of the proprietary format is certainly done in > an FPGA, I tried to calculate how to implement the whole process in an > FPGA. For example, I can take an Altera Stratix II GX (with a built in > Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on > the Nios II soft-core processor. Unfortunately, as Altera's appnote > 440 shows, the maximal bandwidth attainable this way is only 15-17 > MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet > adapters on PCs show a maximal bandwidth of 80-90 MByte/s. > > However, I wouldn't like to build in a Pentium into the embedded > system. Any suggestions / recommendations on how to solve the > problem ? > > Thanks in advance If you have the choice between UDP and TCP, UDP is much simpler and fits an FPGA well. The big issue in choosing between the two is if you require the guaranteed delivery of TCP, or can tollerate the potential packet loss of UDP. As an example, we make a card that acquires real time data in a custom protocol that is wrapped in UDP. We use a Xilinx Virtex-4 FX60, and a protocol offload engine that uses the Xilinx PicoBlaze soft processor to deal with the protocol stack. The PicoBlaze is an 8-bit soft processor. It looks at each incomming packet and reads the header to see if it is one of the real time streams we are trying to offload. If it is, it sends the header to one circular buffer in memory and the data to another circular buffer. If it is not, it sends it to a kernel buffer and we let the Linux network stack deal with it. With this setup, we can consume data at over 90 MB/sec per Gigabit Ethernet port. The data part of the packet is 1024 bytes, and each GigE port has its own PicoBlaze dedicated to it. I did notice that you want to send GigE instead of receive it like we are doing, but this method should work for sending a custom protocol wrapped in UDP with some minor changes. How is the GigE that you are sending the data over connected? Is it point to point, a dedicated network, or something else? The network that the data we deal with is set up as multicast data on VLANs. The VLANs are allocated to guantee the required bandwidth through the switches, and data sources use traffic shapping to put out their packets at a steady rate. In that environment, UDP works just fine. This is the card that I am talking about: http://www.fastertechnology.com/products_p6.html Regards, John McCaskill, www.fastertechnology.comArticle: 123824
> Are you sure that Jim's assertion method in communicating mutually > exclusivity to VHDL compiler is good enough without need for 'orif' > introduction? It depends on the definition of "good enough", but there is not a single situation where an assertion could not reasonably be used, but where 'orif' could be. Conversely, there are several situations where 'orif' is not an option, but an assertion would be. > > 1. As I described before, if you use Jim's method and want to get the > information to compiler, you must insist the 'if...end if' structure > to get the benefits, otherwise it is useless, meaningless and wasting > time. Not necessarily. There are many mutual exclusivity situations that might even span different processes. Consider two processes that both use multipliers. If both processes' uses of their multipliers are enabled by specific conditions that can be shown to be mutually exclusive, the synthesis tool has enough information to enable them to share one multiplier. Of course whether or not current synthesis tools share resources across processes is beyond the scope of this argument. Another example is two state machines that are never both in a state that uses a multiplier (or some other expensive, shareable resource). Both of these situations are certainly possible with if-then code structures, but they don't have to be, and can still take advantage of an assertion to verify and communicate the mutual exclusivity. > > 2. When you use 'if...end if' structure, 'orif' is the best choice, no > question! You can add the information line by line at any levels as > you want. 'Orif' is only an option if you can code the function in an if-ELSIF structure, which cannot be done for a parameterized loop of if-then structures. > > 3. My goal is to make writing VHDL for a hardware engineer as easy as > writing C for a software engineer using 'if...end if' structure with > mixing 'elsif' and 'orif'. Ouch! Then just use verilog; it is already as "easy to use as C" (and to get into trouble with). ;^) The way I see it is thus: The barrier to new syntactical changes in VHDL, particularly those that affect the synthesizable subset of VHDL, should be quite high because of the problems that occur until every tool in the chain can even read the new syntax. Therefore, syntactical changes should only be made to allow functionality that cannot be reasonably supported within the existing syntax. Of course, that depends on the definition of "reasonably", but I just don't think 'orif' exceeds the barrier. Thanks, Andy
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