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
Hi
I'm designing a board which will have an XC2V2000 connected to two external
SRAM chips and an Analog Devices TigerSHARC DSP. The Virtex is clocked by
the 80MHz TigerSHARC bus clock. The internal logic of the Virtex operates
in two clock domains - 80MHz (synchronous to the TigerSHARC clock) and
120MHz (not necessarily synchronous to the TigerSHARC clock). I would like
to interface to the SRAM chips using the 120MHz clock. Xilinx App Note 132
suggests the configuration shown below for distributing a clock to multiple
non-Virtex devices. The bus lengths are very short (approx 40mm) so I'm
planning on connecting the buses directly with no termination and using DCI
if necessary.
Xilinx App Note 132
===================
Please view in a fixed-width font such as Courier.
XC2V2000
+-----------------------------+
| DCM |
| +-------+ |
-----+-IBUFG+-+clkin | |
| | | | |
| | | clk0+----OBUF----+------+
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+---+-IBUFG+-+clkfb | | |
| | | | | | |
| | | +-------+ | |
| | | | |
| | | | |
| | | DCM | |
| | | +-------+ | |
| | +-+clkin | | |
| | | | | |
| | | clk0+----BUFG-+ | |
| | | | | | |
| | | | | | |
| | | | | | |
| | +---+clkfb | | | |
| | | | | | | |
| | | +-------+ | | |
| | +---------------------+ | |
| | | |
| +-----------------------------+ |
| |
| |
+----------------------------------------+
|
|
|
+------- Non-Virtex Device
|
+------- Non-Virtex Device
|
However, I have the following two worries:
1) This seems to suggest a branching clock line. The two SRAMs are on
opposite sides of the Virtex and each branch will be approximately 40mm. At
120MHz, I'm concerned about the reflections/glitches this may cause.
2) Since my input clock is 80MHz and the output 120MHz, I'll have to use the
DCM to multiply the frequency up. This means that I won't be able to feed
the board clock (the clock driving the SRAMs) back into the DCM for
deskewing. I suppose I could cascade two DCM's and use the first one to
multiply up and the second for deskewing....
To be safe, I'm planning on using an zero delay SDRAM clock buffer from
Cypress as shown in the diagram below:
Clock distribution using SDRAM clock buffer
===========================================
Please view in a fixed-width font such as Courier.
XC2V2000
+-----------------------------+ SDRAM clk buffer
| DCM | +------+
| +-------+ | | |
-----+-IBUFG+-+clkin | | | o1|-------+
| | | | | | |
| | clkfx|----OBUF----+-------------+in o2|----+ |
| | | | | | | |
| +--+clk0 | | | o3+-+ | |
| | | | | +------+ | | |
| +--+clkfb | | | | |
| | | IBUFG --+----------------------+ | |
| +-------+ | | | |
| +-----------------+ | SRAM1 | |
| | | +------+ | |
| | DCM | | | | |
| | +-------+ | | +----+ |
| +--+clkin | | | | |
| | | | | | |
| | clk0+----BUFG+ | | | |
| | | | | | | |
| | | | | +------+ |
| | | | | |
| +---+clkfb | | | SRAM1 |
| | | | | | +------+ |
| | +-------+ | | | | |
| +--------------------+ | | | |
| | | | |
+-----------------------------+ | +-------+
| |
| |
+------+
The crucial requirement is for the internal logic running in the 120MHz
domain to be synchronous to the SRAM (not necessarily the 80 MHz input
clock). This means that the situation is slightly different to the app note
which is concerned with ensuring that there is negligible skew between the
board clock and the input clock to the Virtex.
However, from reading a number of posts in the newsgroups about using the
Virtex itself to distribute a board clock I feel that I'm missing something.
Does anyone have any suggestions as to how this could be done better? Am I
justified in my concern over a branching clock line?
Many thanks
Sam Duncan
--
Article: 54751As mentioned in an earlier post I've been developing a SOC using NIOS 3.0 and my own custom logic on a Stratix 1S10 Development Board. I've been trying to interface my custom logic to on-chip memory through the NIOS CPU by creating an Avalon Bus Master. I've set up the entire 1S10 MRAM block as a dual port RAM in the NIOS CPU using SOPC Builder. The NIOS CPU is a bus master for one port of the RAM (through the CPU Data Master Bus) and I've added 2 Avalon Masters to the second port of the RAM. I've had issues where data written to the RAM through the 2 Avalon Masters sometimes doesn't make it. Initially this was due to the address/data/handshake being calculated in a separate, asynchronous, clock domain. I've added the appropriate synchronization blocks between the domains and moved the address calculation into the Avalon Master clock domain. This cleared up about 99% of the dropped writes (as it turns out these dropped writes were really writes to incorrect addresses... I determined this through some extensive software debugging of the memory). Thanks Paul Leventis for the Multiple Clock Domain paper!!!! ( http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk_rev1_1.pdf ) However, I'm still stuck with an occasional failed memory write. Through the same software debugging, it appears that the data was never written to the RAM (at the desired address or otherwise). This makes sense since the address calculation is performed in it the same clock domain one cycle before the initiation of the actual write sequence. In addition, I check that the 'waitrequest' line is low (inactive) before releasing the write_n line. By design, if the write sequence does not execute within 30-35 clock cycles from the receipt of the handshake, it will be aborted. I'm assuming that a Avalon Bus Master write sequence to memory, even with the occasional 'waitrequest', should execute within a few clock cycles. I do not receive any timing warnings through Quartus and the design is completely synchronous (within each clock domain). I've implemented DFF synchronization blocks between the two clock domains but, as I mentioned above, the address calculation is now performed in the Avalon Master code itself so there should be no fear of address corruption. QUESTION: Has anyone else experienced similar problems either using a custom Avalon Bus Master or using the Stratix MRAM as Dual Port RAM? Looking for feedback, thanks! JimArticle: 54752
Hi John.... Static timing analysis must take into acount both setup and hold. You comments about minimum time (hold time) are true, however don't be too conservative. The delays of concern do track at a macroscopic level as they have common voltage, process, and temperature. Don't forget that even for a single clock case you still have hold time issues in the face of clock skew within the distribution tree. The key question is how will you verify that the design will work over all situations. Are you sure those 'others' who have not been able to get their systems operating with two clocks did any sort of hold time analysis? There are yet 'others' who sucessfully use 1x/2x domain crossing again and again using full setup and hold time analysis. Good luck with your design. You are approaching it with the right frame of mind. Eric "John_H" <johnhandwork@mail.com> wrote in message news:3E9EB04A.3090705@mail.com... > I don't belive this will produce 100% results. Using the same DLL is a > requirement to having a chance of working at the high speeds. > > The "same" edge is not necessarily guaranteed to be sourced from the > same input edge through the delay taps to the output. I'd like it if > they were such that input jitter won't produce skew between like edges. > Without details on the DLL innerds, I can't make that call so I err on > the side of caution. > > The clock skews are accounted for in the static timing analysis for > worst case delays. If the longest Tcko, the longest net delays, the > worst case Tsu and clock skew don't exceed your budget, the static > timing analysis declares that you're "golden." Unfortunately, the > "minimum" timing isn't specified. The skew between clocks can result in > the earlier clock producing a result before the destination register > (and associated clock) is clear of its setup/hold window. We have a > guarantee for the same-clock situation where the clock skews are in the > range of 10s of ps but not for the different-clock situation where that > spread is easily in the 100s of ps. > > Other users have been bitten by crossing the 1x and 2x domains on the > "common" rising edge so I'm trying to avoid that assumption that the > edges are safely coincident. > > . . . > > I need to revisit my thoughts to see if I considered using latches > instead of registers for the negedge x2 sampling of the x1 domain. I > might sneak out 100s of ps with latches rather than registers. > > > > Eric Pearson wrote: > > Hi John... > > > > Can't you generate both clocks from the same PLL so the edges stay > > together, and use static timing analysis to handle any clock tree loading > > skews? > > I usually do anything to avoid "clock-the-clock" situations. > > > > Eric > > > > "John_H" <johnhandwork@mail.com> wrote in message > > news:3E9C1B1F.8020305@mail.com... > > > >>Thanks, Ray. > >> > >>I used the RLOCs and double-checked the routing to make sure the numbers > >>were "smallest" and still found myself with almost no margin left over > >>for input jitter tolerance. The Tcko and any of the Tceck or Tdick or > >>Tsrck values along with the shortest net I could muster left the 1.8 ns > >>for 1/4 clock at the hairy edge. I was hoping there was an innovative > >>approach to avoiding the 1.8ns requirement for a 7.2 ns x1clk. > >> > >>- John_H > >> > >>Ray Andraka wrote: > >> > >>>John, You are right ot be concerned about skew between the 1x and 2x > >> > > clocks. If > > > >>>you control placement and are clever about getting direct flip-flop to > >> > > flip-flop > > > >>>connections you can manage to do what you are describing using a falling > >> > > edge > > > >>>sensitive FF in the 2x domain to capture the 1x clock, then take the > >> > > output of > > > >>>the falling edge FF and feed it to a rising edge FF in the 2x domain to > >> > > time > > > >>>align the resulting CE with the 2x clock rising edges. The CE is > >> > > probably > > > >>>inverted WRT to what you wanted at that point, in which case an > >> > > additional > > > >>>rising edge FF will put it right without adding any logic delays in the > >> > > critical > > > >>>timing around the neg edge FF. You'll need to use primitives with RLOCs > >> > > on them > > > >>>to keep the timing tight, and with v4.2 and later tools you need to make > >> > > sure > > > >>>you put the time constraints in for each connection in order to keep the > >> > > router > > > >>>honest (3.3 did a good job of finding the direct connect without having > >> > > an > > > >>>explicit time constraint). > >>> > >>>John_H wrote: > >>> > >>> > >>> > >>>>Thanks for the message last week, Eric - my newsreader at work isn't > >>>>100% and I had to read/respond at home. > >>>> > >>>>Your comment about only needing two flops is accurate as long as the > >>>>designer can trust that the x1clk and x2clk domains will always work > >>>>together as we'd expect where the rising edges are coincident. The > >>>>reality is that those two edges may be separated by some 100s of ps > >>>>since the clock net loading can be different between the two domains and > >>>>input clock jitter to the DLL may translate to the two domains at > >>>>different cycles. THe former problem is known, I'm only speculating on > >>>>the latter. Bottom line: I can't depend on the two domains to play nice > >>>>at the common rising edge, hense the nead to offset things by 1/4 the > >>>>x1clk (or 1/2 th x2clk). > >>>> > >>>>Any further thoughts are appreciated. > >>>> > >>>>- John_H > >>>> > >>>>Eric Pearson wrote: > >>>> > >>>> > >>>>>"John_H" <johnhandwork@mail.com> wrote in message > >>>>>news:T9Hka.9$716.2363@news-west.eli.net... > >>>>> > >>>>> > >>>>> > >>>>>>Has anyone figured out a nice, clean method to track which phase of a > >>>>> > >>>>>Xilinx > >>>>> > >>>>> > >>>>> > >>>>>>DLL's 1x clock corresponds to a 2x clock cycle? One 2x rising edge > >>>>>>corresponds to the 1x rising edge, the other 2x rising edge > >>>>> > > corresponds to > > > >>>>>>the 1x falling edge. > >>>>>> > >>>>>>When I start getting up in frequencies, the ability to use the 1x > >>>>> > > clock > > > >>>>>and > >>>>> > >>>>> > >>>>> > >>>>>>inverted 1x clock to generate two signals that I can XOR for a phase > >>>>> > > is > > > >>>>>>compromised. It's not inherently safe to use the 1x edges and 2x > >>>>> > > rising > > > >>>>>>edges as "effectively" the same edge due to clock skews and input > >>>>> > > jitter > > > >>>>>>issues. Using the falling edge of the 2x clock to sample the 1x > >>>>> > > generated > > > >>>>>>signals works, but at the 1/4 period timing budget is too tight at the > >>>>>>frequencies I'm working. > >>>>>> > >>>>>>For those who are Verilog friendly, the code here shows how I would > >>>>>>"normally" extract the phase without running a clock through a LUT. > >>>>> > > The > > > >>>>>>"negedge x2clk" is where the timing gets tough since the > >>>>> > > Tcko+Tnet+Tick is > > > >>>>>a > >>>>> > >>>>> > >>>>> > >>>>>>little over the 1/4 period of my x1clk. > >>>>>> > >>>>>>always @(posedge x1clk) posTog <= ~posTog; > >>>>>>always @(negedge x1clk) negTog <= posTog; > >>>>>>always @(negedge x2clk) rawPhase <= posTog ^ negTog; > >>>>>>always @(posedge x2clk) phase <= rawPhase; > >>>>>> > >>>>>>Is there a cleaner way to figure out the which half of the x1clk I'm > >>>>> > > in? > > > >>>>>>Thanks, > >>>>>>- John_H > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>>It really only takes 2 flops working on rising edge. > >>>>> > >>>>>always @(posedge x1clk) Toggle <= ~Toggle; > >>>>>always @(posedge x2clk) Delayed <= Toggle; > >>>>>assign Phase = DelTog ^ Tog; > >>>>> > >>>>>Eric > >>>>> > >>>>> > >>>> > >>>-- > >>>--Ray Andraka, P.E. > >>>President, the Andraka Consulting Group, Inc. > >>>401/884-7930 Fax 401/884-7950 > >>>email ray@andraka.com > >>>http://www.andraka.com > >>> > >>> "They that give up essential liberty to obtain a little > >>> temporary safety deserve neither liberty nor safety." > >>> -Benjamin Franklin, 1759 > >>> > >>> > >> > > > > >Article: 54753
Paul Leventis wrote: > > > Looks like the EP1C4 is still not out yet. At least it did not show up > > when I did a web search at Arrow. The approach of providing a smaller > > part with higher IO count is interesting. It fits my needs very well. > > But looks like it is yet to come out. Any idea when? > > Hi Rick, > > EP1C4 is scheduled for release in September 2003. Given the early or > on-time delivery of the other members of the family, this date is pretty > solid. After reading Fredrik's post, I found the release dates by searching the press releases which contained a link. I am curious. Since all the other devices are shipping now, why is the EP1C4 shipping so much later? I saw on the EBV web site that they still don't even list the EP1C4 in the Cyclone Family Overview. Was the EP1C4 added as an afterthought after the other devices had been planned? It seems like 5 months is a long time after all the other family members are out. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 54754
Hi there, is possible to partial reconfigure SpartanIII devices (something similar to partial reconfiguration of VirtexII) ? Thanks SilvanoArticle: 54755
Hi, Just adding a plug for ONEoverT digital filter designer. It will automatically produce synthesizable VHDL for IIRs and FIRs. Very cheap, the demo can be downloaded from the website www.tyder.com If you download the case study, it will show you the implemention of an IIR onto a Spartan FPGA. Yours Alan Mc Kitterick www.tyder.com "Pramod" <pramod@procsys.com> wrote in message news:a7c0720d.0304152101.581c85be@posting.google.com... > Hi All, > I am new to this group and also to the field of FPGA based design. > I have some doubts and issues which I feel will be easy for you guys > to answer. > 1. For a 4 pole IIR Filter in FPGA (targeted device EP1C6), I have a > spec of 24 bit wide data input and > 32 bit wide coeff (dynamic) inputs. So, the multiplied results should > ideally have > 56 bits width. Are these widths practically relevant for a 4 pole > filter > or can we get an affordable precision with rounding to lower sizes? > If so, can anyone suggest a standard procedure for > rounding the results with lowest error and without causing the output > to become unstable? > 2. Another thing I would like to get some advice is, if I go with the > 24 X 36 busses, > since I have to implement a number of such filters in a single device, > the bit-parallel implementation will take up huge resources. > The digit serial approach using (either small multiplier or LUT > method) > also will end up in huge resources due to big number of partial > products and sums involved. > If anyone can suggest any alternate method it will be of great help to > me. > 3. On another front, in a timing simulation scenario I am using > Quartus II .vo output and ModelSIM PE. My code has > a ROM (ALTSYNCRAM megafunction used to generate this). I found some > differences in the > readout data during timing simulation between using .MIF format file > and .HEX format file for initializing ROM > eventhough the QII displayed same contents in the memory editor. > Has anyone ever faced any such issues? > Hoping to get some valuable leads on these.. > Thanks in advance, > PramodArticle: 54760
Anybody know what fpga_edline.exe is? What it is useful for? How to use it?Article: 54761
I have been designing a Digital Signal Processor using the XC2V4000
chip.
Software errors in ISE 4.2 and 5.1 have caused long hours of delay in
developing the design:
Software bugs in SystemAce causes erase problems in the MPM.
Deleting signal wires in ECS causes Fatal errors that crash the
system.
A large design exceeds the 2GB memory limit and generates a fatal
memory error.
I have designed Altera chips for over 6 years and never had a
problem.
All digital designers should stop designing new projects with
Xilinx ICs until Xilinx corrects all software problems with ISE.
Bill Hanna
Article: 54762Hi comp.arch.fpga, I came across a component in Orcad named ADD_BITSLICE, and am thinking what it does. It seems it is not a lower level schematic, neither is it a logiblox/coregen. The ports are: BIT_PREV : in std_logic; BIT_NEW : in std_logic; BYTE0 : in std_logic; BIT0 : in std_logic; CE : in std_logic; CLK : in std_logic; ACC_NEW : out std_logic; I know this may sound silly, but it seems pretty simple to construct this component using AND, XOR and a FF. So why is it a primitive/macro component? I've search many places, but don't seem to find this component. Anyone who can help, thanks! Regards, LCArticle: 54763
Bill Hanna wrote: > > I have been designing a Digital Signal Processor using the XC2V4000 > chip. > Software errors in ISE 4.2 and 5.1 have caused long hours of delay in > developing the design: > > Software bugs in SystemAce causes erase problems in the MPM. > Deleting signal wires in ECS causes Fatal errors that crash the > system. > A large design exceeds the 2GB memory limit and generates a fatal > memory error. > > I have designed Altera chips for over 6 years and never had a > problem. > > All digital designers should stop designing new projects with > Xilinx ICs until Xilinx corrects all software problems with ISE. > > Bill Hanna Perhaps we should be a bit more demanding in the quality of our tools. But if we stopped using them, how would the vendors know what the bugs were, and how would we keep jobs and get paid? With no paycheck, I would not be an engineer anymore and would not care about the tools. Seems rather extreem to me. As good or bad as they are, they are the tools we have. Is this a leadin for a demand for open source tools? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 54764
"Bill Hanna" <billh40@aol.com> wrote in message news:97d137ce.0304171001.5ec5461d@posting.google.com... > I have designed Altera chips for over 6 years and never had a > problem. I was listening until you said that. Sorry but Altera and Xilinx both have a fair share of problems. If you are going to berate Xilinx at least don't ruin the case by unfounded Altera comments. My 0.02cents PaulArticle: 54765
"Bill Hanna" <billh40@aol.com> wrote in message news:97d137ce.0304171001.5ec5461d@posting.google.com... > I have been designing a Digital Signal Processor using the XC2V4000 > chip. > Software errors in ISE 4.2 and 5.1 have caused long hours of delay in > developing the design: > > Software bugs in SystemAce causes erase problems in the MPM. > Deleting signal wires in ECS causes Fatal errors that crash the > system. > A large design exceeds the 2GB memory limit and generates a fatal > memory error. > > I have designed Altera chips for over 6 years and never had a > problem. > > All digital designers should stop designing new projects with > Xilinx ICs until Xilinx corrects all software problems with ISE. > > Bill Hanna Frustration speaking, no doubt, and I sympathize. However, you do have the ability as a customer to take your business elsewhere if you're unhappy with a vendor's products, and that's exactly what you should do. I'd give your Xilinx rep and tech support a chance to get this rectified first (assuming you haven't), and let Xilinx know why you're departing. Otherwise they'll never know that you're unhappy and that there's a problem. If you find a vendor/tool you like better, post about it to the group. Don't expect to find a tool devoid of problems, though. Having written mucho software over the years, I know that a defectless software product isn't going to exist.Article: 54766
Hi Jim, > I found that eliminating my LogicLock regions sped up the compilation > and improved the results. I guess it's true when Altera says you > should only use LogicLock if you know what you're doing. Some recent > feedback from Altera suggested that LogicLock is more of a benefit on > the APEX parts than on the Stratix/Cyclone FPGAs. I have had incredible performance boosts with LogicLock with certain designs, but most of the time performance varies only 10-15%. And, I have seen performance go down as well, so LogicLock is definitely not a magic sword. My personal rule of thumb roughly works as follows: a good indicator with APEX to start thinking about using LogicLock is when the routing delay gets to be more than twice your cell delay in your critical path. If you then examine the entire path, and there are more than two or three interconnects going over 4ns you have a strong contender. If you then look at the offenders and find out in the floorplanner that the source cell drives only one or two destination cells, then you should definitely give it a try. Of course, your mileage may vary ;-) Stratix routing is faster and its behaviour is more linear - with an APEX, as soon as you leave the MegaLAB you get a farly heavy performance hit, with Stratix the delay is more or less linearly dependant on the New York distance (how many LABs horizontal plus how many LABS vertical) between source and destination, all this with a maximum resolution of 4 LABs. Thus, if for some reason there is a bit more distance between two cells, it will not give such a terrible performance hit, and thus the need for LogicLock is less. With Stratix I start looking to LogicLock stuff when the routing gets to be over three times the cell delay, and then roughly follow the APEX procedure. It does still help, but as you have found out, excessive use of LogicLock strongly restricts the placement algorithm and may cause long fitting times. > I'm using a 1.2 GHz Athlon K7 as well... I'm tempted to upgrade to a > P4 but I'm not sure what sort of performance boost I'll see when using > Quartus... tough call on wether to spend the money. Quartus is quite CPU hungry, but it's an unmatched memory bandwidth eater, and your CPU might as well not have a cache. So, if you do spring for a faster CPU, make sure that it has a matching memory subsystem. Use CL2 DDR333 or DDR400 SDRAM, or 800MHz RDRAM, and pick a motherboard with a good memory controller. Personally I'm aiming for an Athlon XP 3000+ - I still think they're more bang for the buck at about $400. But then I would also have to swap my 1GB CL2 DDR266 SDRAM out again... Oh, those luxury problems ;-) Good luck, BenArticle: 54767
Hi Rick, > Was the EP1C4 > added as an afterthought after the other devices had been planned? It > seems like 5 months is a long time after all the other family members > are out. Since the Cyclone family spec was based on a lot of customer feedback, I guess that it took five months of customers complaining about too little I/O per LE in the Cyclone family to get this one started ;-) By the way, if you install Quartus II 2.2 service pack 2 you can already start designing for it. Best regards, BenArticle: 54768
> After reading Fredrik's post, I found the release dates by searching the > press releases which contained a link. If you go to the 'Overview' page on the Cyclone web site, it also lists the Production availability dates -- Sept 2003 is for production devices. http://www.altera.com/products/devices/cyclone/overview/cyc-overview.html > I am curious. Since all the other devices are shipping now, why is the > EP1C4 shipping so much later? I saw on the EBV web site that they still > don't even list the EP1C4 in the Cyclone Family Overview. Was the EP1C4 > added as an afterthought after the other devices had been planned? It > seems like 5 months is a long time after all the other family members > are out. Really the anomally is rolling out (to full production status, no less) four devices in three months -- when you look at the roll-out of other FPGA families, 9 months from first to last member is not abnormal. The technical reason: In order to achieve the higher IO density on the 1C4, we use a staggered (vs. linear) pad ring, which required a small amount of additional design, verification and software modeling effort. All the other Cyclone members use a linear pad ring and share the same IO building blocks -- that's why we could stamp them out so quickly. Regards, Paul Leventis Altera Corp.Article: 54769
I'm would like to use rloc directly in verilog. Yet it does not work. I use the ISE design flow with the XST synthesis on a Virtex2. Below you can find the code. It consists of 2 gates in parallel followed by 2 registers in parallel followed by 2 gates in parallel. After place and route the 2 registers are in the same slice. But this is not according to the rloc statement. Can anybody tell me what I'm doing wrong? Also where can I find a good tutorial regarding how to create macros (with/without the fpga editor)? Kris //////////////////////////////////////////////////////////////////////////// ///////////////////////// module REGS(clk, ina, inb, outa, outb); input clk, ina, inb; output outa, outb; wire in1, in2, out1, out2; //-- logic assign in1= ina|inb; assign in2 = ina&inb; assign outa = out1|out2; assign outb = out1&out2; //-- registers REG1 REG1a(clk, in1, out1); REG2 REG2a(clk, in2, out2); endmodule module REG1(clk, in, out); input clk, in; output out; reg out; always @(posedge clk) begin out <= in; end endmodule module REG2(clk, in, out); input clk, in; output out; reg out; always @(posedge clk) begin out <= in; end endmodule // synthesis attribute u_set of REG1a is set1; // synthesis attribute rloc of REG1a is X0Y0; // synthesis attribute u_set of REG2a is set1; // synthesis attribute rloc of REG2a is X3Y3;Article: 54770
Wow - the Cyclone may now be a contender! As much I/O available as in the largest EP1C20 but just slightly more logic than the smallest EP1C3. "Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl> wrote in message news:ViDna.2090$KF1.84443@amstwist00... > Hi Rick, > > > Was the EP1C4 > > added as an afterthought after the other devices had been planned? It > > seems like 5 months is a long time after all the other family members > > are out. > > Since the Cyclone family spec was based on a lot of customer feedback, I > guess that it took five months of customers complaining about too little I/O > per LE in the Cyclone family to get this one started ;-) > > By the way, if you install Quartus II 2.2 service pack 2 you can already > start designing for it. > > Best regards, > > > > BenArticle: 54771
"Matt Giwer" <jull43@tampabay.rr.com> wrote in message news:Ri_ma.155738$j8.3403659@twister.tampabay.rr.com... > > Even then, each processor would create an output file in the chosen > format with all the right headers. So they would have to be processed to > reassemble instead of simply concatenating them. Ideally instead of each > processor writing to its own file it would send the results to one > computer which would then create a single output file. That would be > another interesting rewrite. > > That is why so far I have only addressed the trivial issue of > animations where the number of frames is assigned by clock speed. > I'm writing my own raytracer that does this (although by no means POV-Ray quality, I don't have much up right now). My idea is to dole out bunches of rays to each proc (or maybe specify a light and have each proc produce rays), and after that all the reflected rays are split up and redistributed according to how fast each proc is (by a simple benchmark, maybe rays/sec or something).Article: 54772
> > I'm using a 1.2 GHz Athlon K7 as well... I'm tempted to upgrade to a > > P4 but I'm not sure what sort of performance boost I'll see when using > > Quartus... tough call on wether to spend the money. Assuming you are limited by the place & route time (as most non-toy designs are), then take a look at the SPEC 2000 benchmark, in particular the SPEC Int test "175.vpr". This test is based on the academic VPR tool, which is a simulated annealing-based placer and negotiated congestion router for an FPGA. The results of this test should correlate reasonably well with Quartus run times, or pretty much any place & route CAD tool. In some informal testing, we've found the results hold up pretty well (in particular, that a P4 has to have a high clock rate to beat out a P3). Web site: www.spec.org/cpu2000 Some results I grabbed randomly: AMD XP 3000+: 215 3.06 Ghz P4 231 1.4 Ghz P3 283 1.5 Ghz P4 460 Athlon 1.2 Ghz 549 Of course, this ignores the impact of the memory sub-system... Regards, Paul Leventis Altear Corp.Article: 54773
Bill Hanna wrote: > > Software bugs in SystemAce causes erase problems in the MPM. For development, consider downloading from the host or flash file system. > Deleting signal wires in ECS causes Fatal errors that crash the > system > A large design exceeds the 2GB memory limit and generates a fatal > memory error. Consider using an HDL for large designs. > > I have designed Altera chips for over 6 years and never had a > problem > All digital designers should stop designing new projects with > Xilinx ICs until Xilinx corrects all software problems with ISE. Consider synthesis to isolate yourself somewhat from the brand differences. The devices and the vendor-supplied front end tools don't have to be used together. -- Mike TreselerArticle: 54774
Little addition: > Quartus is quite CPU hungry, but it's an unmatched memory bandwidth eater, > and your CPU might as well not have a cache. So, if you do spring for a > faster CPU, make sure that it has a matching memory subsystem. Use CL2 > DDR333 or DDR400 SDRAM, or 800MHz RDRAM, and pick a motherboard with a good > memory controller. See for a nice comparison chart: http://www.tomshardware.com/mainboard/20030303/amd_athlon-03.html If I were to switch from my current AMD760-based motherboard to one using the nForce chipset I could easily gain 20% performance, while keeping the rest of my system the same...
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