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
"Anom" <searchfordesignservices@hotmail.com> wrote in message news:671a04d4.0410220739.8d21b45@posting.google.com... > Hi, > > For a quite large project dealing with Virtex 4, DDR2, gigabit > ethernet and digital signal processing, I'm looking for a top of the > bill design house in a far east country like india. > > All tips are welcome. > > Best Regards, > Anom They dont exist.. and the one's you deal with will cost you more in the final analysis than if you had it done properly here or in europe..Article: 75001
"Austin Lesea" <austin@xilinx.com> wrote in message news:clbrqm$251@cliff.xsj.xilinx.com... > Thomas, > > We did this to prove a point (that we could do clock and data recovery by > such a scheme). > > So while you advance one DLL phase, the other is waiting at its minimum > (or maximum) until you are about to (undeflow) overflow. Then you switch > DLLs (using a BUFGMUX) and trade roles for the DCM's (one is now the > source of the clock, and the other is set to max or min based on the > direction you wish to move the phase). > > It gave a number of folks a headache here as well, but it did work, and > was able to act as CDR to recover data from a 270 Mbs data stream. > > My thought was to always have one DLL be a mirror of the other (if one > advances, the other goes back) so that when you reach 0, the other is at > max, and if you reach 255, the other is at 0, and use the BUFGMUX to > switch between them when you need to. They ended up not doing it that > way, but I saw no reason why not. Maybe they hit on a simpler control > scheme their way. > > This does not make a VCXO however (always get the same frequency out). > > Austin Austin, Did you do that for DVB-ASI? I ask because the data rate is 270Mbps. I tried to do something similar for ASI but using a carry chain--the number that got "added" to the clock controlled how long it took the clock to propagate through the carry chain. An NCO controlled where the clock got injected into the carry chain. It worked pretty well in the post-synthesis sim but the gate-level sim wouldn't work and I gave up on it. There were also some glitches to be resolved. I'd disagree that you always get the same frequency out. Phase is the derivative of frequency, so if you are adding phase that is changing linearly, that is the same as adding a constant value to the freqency, thereby changing the frequency to a new one. -KevinArticle: 75002
Hello people. Just to inform you that PacoBlaze 1.3b is out. The are no changes to the KCPSMx cores, KCAsm has been enhanced and now supports all the PicoBlaze architectures. Work will continue to merge BlockRAM generation across target platforms. Thanks for all who have submitted suggestions and bug reports. Cheers! -- PabloBleyerKocik /"Computers are like Old Testament gods; pbleyer2004 / lots of rules and no mercy." @embedded.cl / -- Joseph CampbellArticle: 75003
Moti Cohen wrote: >>> >>> >>> >>> >>Do not know if this was addressed before. Do you use a four layer PCB >>carefully decoupled with capacitors? >>Is your ground bounce ok? Do you have contentions on your board? Did you >>try to put the outputs into slow >>smooth switching mode? >> >> > > >- I'm using a 10 layers PCB and I believe that I decoupled the voltage >supply inputs as needed ( three levels of capcitors values). > >- I dont have any contentions on the board (I tested it on several >boards) - and the current consumption is o.k. + the chip does not warm >up + the same pin assignment file is used in cases when the chip does >works. > >- I guess that by "smooth switching mode" you mean "Slow slew rate" so >at the begining I did tried to set the outputs to slow slew rate but >without any success. > >I didnt checked for ground bounces - but my design does not contains >many outputs that change on the same time and along with using slow >slew rate outputs I hope that I should not worry about ground/VCC >bouncing problems. > > > > Looks like a very proper design. Another idea: Do you have floating inputs? >>It looks to me like you switch off a bank by switching and the result >>depends on what is fitted into this bank. >> >> > >I'm not sure what you meant by "switching off a bank" I will be glad >if you explain it.. > > > Chips have multiple VCC/GND inputs to parts of the chip. If you overload a section it is likely that because of the supply break down caused by this in the section flip flops might flip. Texas Instruments has a very good app note: scba004c.pdf Another thing is tiying the design. I am not familia with the latest software and just figuring out some things either. But on Foundation there was a tie option to tie unused inputs to defined logic levels. I know from the past that you can test designs without tie to save time but they were not that reliable like tied design. Regards ThomasArticle: 75004
Has any tried to write a SCSI core?Article: 75005
Kevin, Yes, if you continuously add phase, you can change the frequency (slightly). Since you can't add phase faster than the DCMs will let you (~100 clocks per update), the range is only +/- 50 ppm or so....if my memory serves me right here. There was no specific application in mind. There are two app notes on CDR for the 270 Mbs app you mention, one that uses the carry chain, and one that uses an oscillator. Hope this helps, AustinArticle: 75006
Antti, OK, I must be missing something here. Excuse my ignorance. Are you looking for HDL source code for some apps? Are you looking for c code for the PPC? Are you looking for schematics? There is just so much to the word "source" that it isn't registering, Sorry to be obtuse, Austin Antti Lukats wrote: > "austin" <austin@xilinx.com> wrote in message > news:cldust$8id1@cliff.xsj.xilinx.com... > >>Pete, >> >>To what are you referring? >> >>If you can detail what you are looking for, maybe we can help you? >> >>Austin >> >>Pete Fraser wrote: >> >> >>>When will the design sources for the ML401 >>>demo projects be available? > > > Hi is looking for project sources for the new Xilinx V4 low cost development > kit ML401 ! > > looks qute, but as he said there are no project source codes on Xilinx > website only demo images :( > > Antti > >Article: 75007
> The Nios is 32-bit data, the memories are > 16-bit data. Using SignalTap I can see that Nios is only accessing > even addresses in the external memory Hi Alan: A classic situation. The CPU references each byte (8 bits) in memory using address bit 0. But the CPU accesses memory in 2 byte chunks (16 bits) so the CPU only needs to output even addresses. If the program accesses a byte of data from memory, the CPU reads the 16 bits (even address) containing that byte and the data bus interface directs either the high byte or the low byte into the low 8 bits on the CPU input bus. If you had a 32 bit wide memory bus the CPU would only read addresses divisible by 4 and then direct one of the 4 bytes appropiately. gmArticle: 75008
Spike wrote: > Has any tried to write a SCSI core? <ftp://137.193.64.130/pub/xproz> if you are looking for a soft_and_slow one vax, 9000Article: 75009
"austin" <austin@xilinx.com> wrote in message news:clgg8e$qq2@cliff.xsj.xilinx.com... > Antti, > OP (Pete) here. > OK, I must be missing something here. Excuse my ignorance. The ML401 is a cool looking Virtex 4 development board made and sold by Xilinx. I should have one on Monday or Tuesday. > Are you looking for HDL source code for some apps? I'm looking for HDL and C source code for the demo apps that are shipped with the board. > Are you looking for c code for the PPC? I don't believe there is a PPC on it (4VLX25). > Are you looking for schematics? Got them. Thanks. > There is just so much to the word "source" that it isn't registering, > > Sorry to be obtuse, I should have explained in more detail. I just assume you'd be familiar with the board. http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=PRODUCTS&sSecondaryNavPick=Design+Tools&category=&iLanguageID=1&key=HW-V4-ML401-USA http://www.xilinx.com/products/boards/ml401/reference_designs.htm "Note: Many of these demonstration programs were developed using advance versions of the EDK 6.3 tools. The project files and hardware/software source files will be released when these tools are released. Contact your local Xilinx Field Applications Engineer or Sales Office for more information." PeteArticle: 75010
"austin" <austin@xilinx.com> wrote in message news:cldust$8id1@cliff.xsj.xilinx.com... > Pete, > > To what are you referring? > > If you can detail what you are looking for, maybe we can help you? > > Austin > > Pete Fraser wrote: > > > When will the design sources for the ML401 > > demo projects be available? Hi is looking for project sources for the new Xilinx V4 low cost development kit ML401 ! looks qute, but as he said there are no project source codes on Xilinx website only demo images :( AnttiArticle: 75011
"TheDoc" <TheDoc@ev1.net> wrote in message news:<10nlji0rrd8rr14@corp.supernews.com>... > "Anom" <searchfordesignservices@hotmail.com> wrote in message > news:671a04d4.0410220739.8d21b45@posting.google.com... > > Hi, > > > > For a quite large project dealing with Virtex 4, DDR2, gigabit > > ethernet and digital signal processing, I'm looking for a top of the > > bill design house in a far east country like india. > > > > All tips are welcome. > > > > Best Regards, > > Anom > > They dont exist.. and the one's you deal with will cost you more in the > final > analysis than if you had it done properly here or in europe.. They exists, but not cheap. Low skill labor costs in China/India are USD$1 per hour. High skill labor costs are over USD$10 per hour, plus another USD$5 management/government fees. Another consideration is that unless you are planning on open-source, there is no way to protect your invested IP.Article: 75012
I've been working on a DDR SDRAM controller for a Virtex-II Pro 7 (ff896 package, speed grade 5) So far I've tried the controller from OpenCores, and looked at some of the app notes from Xilinx. I was looking at App Note 253 in particular, but someone on the Xilinx forums said that he had only been able to get it work with the test bench, not in the real world yet. This is the same problem I spent about 3 weeks on for the OpenCores controller. I am using the Avnet evaluation board, which has 2 Micron mt46v16m16 chips, with 16 data lines each. All lines are common between the two except for DM, DQS, CS#, CLK/CLK#, and data. The data interface to the FPGA is 32 bits wide (16 from each chip). Can anyone suggest what app note, or other free IP, would be the best place to start? For this project, we want our custom logic talking directly to the memory controller, and probally will not be using the on-chip PowerPC. I've looked at modifing the DDR control from the Xilinx EDK, but someone in the Embedded Processing Division told me it would be easier to make a state machine to "fake" the OPB bus signaling. Is that actaully the best way for me to go, or is there something simpler? Thanks, MikeArticle: 75013
This is not what you asked for - these guys are in the US. They've done a good job for me in the past. They have experience with these sorts of designs and parts: www.bostondesignsolutions.com Chris searchfordesignservices@hotmail.com (Anom) wrote in message news:<671a04d4.0410220739.8d21b45@posting.google.com>... > Hi, > > For a quite large project dealing with Virtex 4, DDR2, gigabit > ethernet and digital signal processing, I'm looking for a top of the > bill design house in a far east country like india. > > All tips are welcome. > > Best Regards, > AnomArticle: 75014
Do you have a link for this. Google can not find it. Pablo Bleyer Kocik wrote: > Hello people. > > Just to inform you that PacoBlaze 1.3b is out. The are no changes to > the KCPSMx cores, KCAsm has been enhanced and now supports all the > PicoBlaze architectures. Work will continue to merge BlockRAM > generation across target platforms. > > Thanks for all who have submitted suggestions and bug reports. > > Cheers! > > -- > PabloBleyerKocik /"Computers are like Old Testament gods; > pbleyer2004 / lots of rules and no mercy." > @embedded.cl / -- Joseph Campbell >Article: 75015
Pete, Got it. Will take it from here. Thanks. We have >8 pcbs that were done for V4 launch alone by Xilinx (let alone the ones done by our partners), and I am not familiar with the details of each one, Austin Pete Fraser wrote: > "austin" <austin@xilinx.com> wrote in message > news:clgg8e$qq2@cliff.xsj.xilinx.com... > >>Antti, >> > > OP (Pete) here. > > >>OK, I must be missing something here. Excuse my ignorance. > > > The ML401 is a cool looking Virtex 4 development board made > and sold by Xilinx. I should have one on Monday or Tuesday. > > >>Are you looking for HDL source code for some apps? > > > I'm looking for HDL and C source code for the demo apps > that are shipped with the board. > > >>Are you looking for c code for the PPC? > > > I don't believe there is a PPC on it (4VLX25). > > >>Are you looking for schematics? > > > Got them. Thanks. > > >>There is just so much to the word "source" that it isn't registering, >> >>Sorry to be obtuse, > > > I should have explained in more detail. > I just assume you'd be familiar with the board. > > http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=PRODUCTS&sSecondaryNavPick=Design+Tools&category=&iLanguageID=1&key=HW-V4-ML401-USA > > http://www.xilinx.com/products/boards/ml401/reference_designs.htm > > "Note: Many of these demonstration programs were developed using advance > versions of the EDK 6.3 tools. The project files and hardware/software > source > files will be released when these tools are released. Contact your local > Xilinx > Field Applications Engineer or Sales Office for more information." > > Pete > >Article: 75016
hamilton wrote: > > Do you have a link for this. Google can not find it. > > Pablo Bleyer Kocik wrote: > > Hello people. > > > > Just to inform you that PacoBlaze 1.3b is out. The are no changes to > > the KCPSMx cores, KCAsm has been enhanced and now supports all the > > PicoBlaze architectures. Work will continue to merge BlockRAM > > generation across target platforms. > > > > Thanks for all who have submitted suggestions and bug reports. > > > > Cheers! > > > > -- > > PabloBleyerKocik /"Computers are like Old Testament gods; > > pbleyer2004 / lots of rules and no mercy." > > @embedded.cl / -- Joseph Campbell http://armoid.com/pacoblaze He talked about this earlier in another thread. -- 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: 75017
Pablo Bleyer Kocik wrote: > > Hello people. > > Just to inform you that PacoBlaze 1.3b is out. The are no changes to > the KCPSMx cores, KCAsm has been enhanced and now supports all the > PicoBlaze architectures. Work will continue to merge BlockRAM > generation across target platforms. > > Thanks for all who have submitted suggestions and bug reports. Do you have any statistics for size and speed in different targets? How does it compare to the Xilinx core? -- 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: 75018
Hi Mike, Mike Peattie wrote: > I have written an assembler for PicoBlaze (KCPSM3) in Perl. It's working [snip] > I'd like to make a call for test cases, or potential users. Please email > me if you're at all interested. It's possible that this script may be > included in future distributions of PicoBlaze. I could be interested in this - but mostly from the perspective of using it as a base to port the assembler into C. I have some done some experiments with arrays of picoblazes connected to a central microblaze (running uClinux of course), with the microblaze dynamically reprogramming and communicating with the Picoblazes, scheduling tasks on them and things like this. Currently I have to assemble the picoblaze code on a desktop machine, and just download the .bin files from the microblaze to the pico-nodes. I could run perl on the microblaze then use your scripts on top of that, but it would be pretty heavy-weight - a direct C implementation would be much smaller. I've never written an assembler, maybe it's time to try! Regards, JohnArticle: 75019
It has a 168 LED matrix display, which for the ALtera demo app alternates between time and
a scrolling date with the month spelled out. The demo also supports using the display for
a stock ticker, and another load uses it for a pong game.
The board also has a VGA connector and has a VGA DAC on it so that it can drive a VGA
monitor. The demo has an altera logo with a cube of dots that rotates around in 3
dimensions on the VGA display. There is also a usb connector and 10 user pins on a 0.10"
two row header. The board is cast into a solid block of acrylic (I understand it was
quite the engineering feat to do that alone). Sorry, no snowflakes, unless you program
the display to simulate snow flakes. The LEDs are red surface mount devices.
Jeff Cunningham wrote:
> I may be slow today, but the web site doesn't seem to have any details
> about this thing or a large picture. I assume it has some IO other than
> a USB cable? Does it light up? Can you shake it and watch the snow fall?
--
--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: 75020"Mike Delaney" <mmdst23_NOSPAM_@pitt.edu> wrote in message news:2zRed.3331$Ae3.899@trndny02... > I've been working on a DDR SDRAM controller for a Virtex-II Pro 7 (ff896 package, speed grade 5) > So far I've tried the controller from OpenCores, and looked at some of the app notes from Xilinx. I was looking at App Note 253 in particular, but someone on the Xilinx forums said that he had only been able to get it work with the test bench, not in the real world yet. This is the same problem I spent about 3 weeks on for the OpenCores controller. > I am using the Avnet evaluation board, which has 2 Micron mt46v16m16 chips, with 16 data lines each. All lines are common between the two except for DM, DQS, CS#, CLK/CLK#, and data. The data interface to the FPGA is 32 bits wide (16 from each chip). > Can anyone suggest what app note, or other free IP, would be the best place to start? For this project, we want our custom logic talking directly to the memory controller, and probally will not be using the on-chip PowerPC. I've looked at modifing the DDR control from the Xilinx EDK, but someone in the Embedded Processing Division told me it would be easier to make a state machine to "fake" the OPB bus signaling. Is that actaully the best way for me to go, or is there something simpler? > > Thanks, > Mike There possible isnt such thing you are looking for :( that is anything that can be found either does not work "out of box" or needs to be modified heavily. I found the same thing to be true for SDR SDRAM as well. Ended (ending) up almost rewriting from scratch. For you - get an working EDK design for your board, get it working, attach chipscope the DDR io's make some snapshots - then start with some core you are going to use for your own purposes and at each step try to compare whats different (if your modified core doesnt work). Sure you can achive something with pure simulations also, but in any case you are looking at some week worth of time to get your custom DDR core working in FPGA (that my thumb estimate, if you are very lucky can maybe stretch a few days) AnttiArticle: 75021
Hi Kedar, Kedar P. Apte wrote: > I have subscribed my email for that list let us see > I need more info on if any body had done partial reconfiguration in > Xilinx when a part of FPGA is already active Yes it works, it can be done, I've done it, so have many other people. But, it's not easy, in fact it's downright difficult and painful. If you are going to spend effort working on this, you must have a very good reason - only you can be certain of that. > So in that details about tools used configuration modes and a bit of > hardware configuration required and finally does it work Start by reading this document: http://www.xilinx.com/bvdocs/appnotes/xapp290.pdf Once you've read it, then read it again. Probably read it a 3rd time. Then, step through the various steps described, using the simple design files that Xilinx provides. Until you truly understand every step of the process described in XAPP290, there is simply no point trying to do it yourself, on your own designs etc. I say this from painful experience! You should also have available the manual for the XST tools - they are distributed in PDF form with ISE. In particular, the options to NGDBUILD, MAP, and PAR, relating to partial reconfiguration are documented. You must read these very carefully - when I first started I looked at them, thought "yes, that's easy", but then couldn't get it to work. The problem was always that I had missed some tiny detail. Good luck! JohnArticle: 75022
Hello there,
I've got a hard-wired asyncrhonous reset coming into GCK on a Spartan
XC2S200 device. The reset is used within three different processes in
VHDL code. However, beyond Synthesis and Translation, ISE errors
during Mapping. Apparently it is trying to control the packing of
flip-flops or latches within an I/O cell. Normally, the Mapper packs
devices within an I/O cell only if such packing is specified by the
design entry method. However, I don't do this intentially. I can't
move the reset to a general I/O as it is fixed in hardware. My
experience has not been good with GCK's as I/Os beside clock use. I
can't change the LOC constraint in the UCF to a different physical
location as this is the only reset available. How can I get rid of
this error w/o modifying the code? Tnx,
YZ
-- MAPPING ERROR
ERROR:Pack:1107 - Unable to combine the following symbols into a
single IOB component: PAD symbol "Rx_Reset" (Pad Signal = Rx_Reset)
BUF symbol "Rx_Reset_IBUF" (Output Signal =
Rx_Reset_IBUF)
Each of the following constraints specifies an illegal physical site
for a component of type
IOB: Symbol "Rx_Reset" (LOC=P77)
Please correct the constraints accordingly.
Article: 75023Here are parts of the synthesis reports for the naked core of an KCPSM3 in a SpartanII (XC2S100): PacoBlaze: ========================================================================= * Final Report * ========================================================================= Final Results RTL Top Level Output File Name : kcpsmx.ngr Top Level Output File Name : kcpsmx Output Format : NGC Optimization Goal : Area Keep Hierarchy : NO Design Statistics # IOs : 58 Macro Statistics : # RAM : 3 # 16x8-bit dual-port distributed RAM: 1 # 32x10-bit single-port distributed RAM: 1 # 64x8-bit single-port distributed RAM: 1 # Registers : 19 # 1-bit register : 16 # 10-bit register : 1 # 5-bit register : 2 # Multiplexers : 10 # 1-bit 4-to-1 multiplexer : 1 # 2-to-1 multiplexer : 9 # Adders/Subtractors : 3 # 10-bit adder : 1 # 5-bit addsub : 1 # 8-bit adder carry in/out : 1 # Xors : 1 # 1-bit xor8 : 1 Cell Usage : # BELS : 273 # GND : 1 # LUT1 : 13 # LUT2 : 16 # LUT3 : 108 # LUT4 : 91 # MUXCY : 21 # MUXF5 : 1 # VCC : 1 # XORCY : 21 # FlipFlops/Latches : 46 # FDE : 2 # FDR : 11 # FDRE : 29 # FDRS : 2 # FDS : 2 # RAMS : 34 # RAM16X1D : 8 # RAM32X1S : 26 # Clock Buffers : 1 # BUFGP : 1 # IO Buffers : 57 # IBUF : 28 # OBUF : 29 ========================================================================= Device utilization summary: --------------------------- Selected Device : 2s100etq144-6 Number of Slices: 200 out of 1200 16% Number of Slice Flip Flops: 46 out of 2400 1% Number of 4 input LUTs: 288 out of 2400 12% Number of bonded IOBs: 57 out of 102 55% Number of GCLKs: 1 out of 4 25% ========================================================================= TIMING REPORT NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT GENERATED AFTER PLACE-and-ROUTE. Clock Information: ------------------ -----------------------------------+------------------------+-------+ Clock Signal | Clock buffer(FF name) | Load | -----------------------------------+------------------------+-------+ clk | BUFGP | 80 | -----------------------------------+------------------------+-------+ Timing Summary: --------------- Speed Grade: -6 Minimum period: 21.627ns (Maximum Frequency: 46.238MHz) Minimum input arrival time before clock: 24.700ns Maximum output required time after clock: 8.320ns Maximum combinational path delay: 10.734ns Timing Detail: -------------- All values displayed in nanoseconds (ns) ------------------------------------------------------------------------- Timing constraint: Default period analysis for Clock 'clk' Delay: 21.627ns (Levels of Logic = 16) Source: register_Mram_dpr_inst_ramx_3 (RAM) Destination: zero (FF) Source Clock: clk rising Destination Clock: clk rising Data Path: register_Mram_dpr_inst_ramx_3 to zero Gate Net Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- ------------ RAM16X1D:WCLK->DPO 2 1.568 1.150 register_Mram_dpr_inst_ramx_3 (register_y_data_out<3>) LUT3:I2->O 35 0.468 3.375 scratch_address<3>1 (scratch_address<3>) LUT3:I2->O 1 0.468 0.000 alu_Madd__n0021_inst_lut2_171 (alu_Madd__n0021_inst_lut2_17) MUXCY:S->O 1 0.515 0.000 alu_Madd__n0021_inst_cy_18 (alu_Madd__n0021_inst_cy_18) MUXCY:CI->O 1 0.058 0.000 alu_Madd__n0021_inst_cy_19 (alu_Madd__n0021_inst_cy_19) MUXCY:CI->O 1 0.058 0.000 alu_Madd__n0021_inst_cy_20 (alu_Madd__n0021_inst_cy_20) MUXCY:CI->O 1 0.058 0.000 alu_Madd__n0021_inst_cy_21 (alu_Madd__n0021_inst_cy_21) XORCY:CI->O 1 0.648 0.920 alu_Madd__n0021_inst_sum_22 (alu_addsub_result<7>) LUT4:I1->O 1 0.468 0.920 alu__old_result_6<7>53 (CHOICE603) LUT4:I3->O 3 0.468 1.320 alu__old_result_6<7>61 (alu_result<7>) LUT3:I1->O 1 0.468 0.000 alu_Mmux__n0004_inst_mux_f5_0111_G (N11696) MUXF5:I1->O 2 0.403 1.150 alu_Mmux__n0004_inst_mux_f5_0111 (alu_shift_bit) LUT4:I1->O 1 0.468 0.920 alu__old_result_6<0>29 (CHOICE463) LUT4:I2->O 3 0.468 1.320 alu__old_result_6<0>61 (alu_result<0>) LUT3:I1->O 1 0.468 0.920 Mmux__n0016_Result24 (CHOICE447) LUT3:I1->O 1 0.468 0.920 Mmux__n0016_Result49_SW0 (N11635) LUT4:I3->O 1 0.468 0.000 Mmux__n0016_Result49 (N10428) FDRE:D 0.724 zero ---------------------------------------- Total 21.627ns (8.712ns logic, 12.915ns route) (40.3% logic, 59.7% route) ------------------------------------------------------------------------- Timing constraint: Default OFFSET IN BEFORE for Clock 'clk' Offset: 24.700ns (Levels of Logic = 14) Source: instruction<17> (PAD) Destination: zero (FF) Destination Clock: clk rising Data Path: instruction<17> to zero Gate Net Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- ------------ IBUF:I->O 30 0.797 3.250 instruction_17_IBUF (instruction_17_IBUF) LUT3:I1->O 3 0.468 1.320 alu_Ker71491 (alu_N7151) LUT3:I0->O 9 0.468 2.150 alu__n00191 (alu__n0019) LUT3:I0->O 8 0.468 2.050 alu_Ker707067 (N9028) LUT3:I2->O 1 0.468 0.920 alu__old_result_6<7>53_SW0 (N11655) LUT4:I2->O 1 0.468 0.920 alu__old_result_6<7>53 (CHOICE603) LUT4:I3->O 3 0.468 1.320 alu__old_result_6<7>61 (alu_result<7>) LUT3:I1->O 1 0.468 0.000 alu_Mmux__n0004_inst_mux_f5_0111_G (N11696) MUXF5:I1->O 2 0.403 1.150 alu_Mmux__n0004_inst_mux_f5_0111 (alu_shift_bit) LUT4:I1->O 1 0.468 0.920 alu__old_result_6<0>29 (CHOICE463) LUT4:I2->O 3 0.468 1.320 alu__old_result_6<0>61 (alu_result<0>) LUT3:I1->O 1 0.468 0.920 Mmux__n0016_Result24 (CHOICE447) LUT3:I1->O 1 0.468 0.920 Mmux__n0016_Result49_SW0 (N11635) LUT4:I3->O 1 0.468 0.000 Mmux__n0016_Result49 (N10428) FDRE:D 0.724 zero ---------------------------------------- Total 24.700ns (7.540ns logic, 17.160ns route) (30.5% logic, 69.5% route) ------------------------------------------------------------------------- Timing constraint: Default OFFSET OUT AFTER for Clock 'clk' Offset: 8.320ns (Levels of Logic = 1) Source: register_Mram_dpr_inst_ramx_7 (RAM) Destination: out_port<7> (PAD) Source Clock: clk rising Data Path: register_Mram_dpr_inst_ramx_7 to out_port<7> Gate Net Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- ------------ RAM16X1D:WCLK->SPO 9 1.568 2.150 register_Mram_dpr_inst_ramx_7 (out_port_7_OBUF) OBUF:I->O 4.602 out_port_7_OBUF (out_port<7>) ---------------------------------------- Total 8.320ns (6.170ns logic, 2.150ns route) (74.2% logic, 25.8% route) ------------------------------------------------------------------------- Timing constraint: Default path analysis Delay: 10.734ns (Levels of Logic = 3) Source: instruction<10> (PAD) Destination: out_port<7> (PAD) Data Path: instruction<10> to out_port<7> Gate Net Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- ------------ IBUF:I->O 10 0.797 2.250 instruction_10_IBUF (instruction_10_IBUF) RAM16X1D:A2->SPO 9 0.935 2.150 register_Mram_dpr_inst_ramx_1 (out_port_1_OBUF) OBUF:I->O 4.602 out_port_1_OBUF (out_port<1>) ---------------------------------------- Total 10.734ns (6.334ns logic, 4.400ns route) (59.0% logic, 41.0% route) PicoBlaze: ========================================================================= * Final Report * ========================================================================= Final Results RTL Top Level Output File Name : kcpsm3.ngr Top Level Output File Name : kcpsm3 Output Format : NGC Optimization Goal : Area Keep Hierarchy : NO Design Statistics # IOs : 58 Cell Usage : # BELS : 196 # GND : 1 # INV : 3 # LUT1 : 2 # LUT2 : 6 # LUT3 : 71 # LUT4 : 30 # MUXCY : 39 # MUXF5 : 9 # VCC : 1 # XORCY : 34 # FlipFlops/Latches : 86 # FD : 21 # FDE : 2 # FDR : 33 # FDRE : 8 # FDRSE : 20 # FDS : 2 # RAMS : 18 # RAM16X1D : 8 # RAM32X1S : 10 # Clock Buffers : 1 # BUFGP : 1 # IO Buffers : 57 # IBUF : 28 # OBUF : 29 # Others : 8 # RAM64X1S : 8 ========================================================================= Device utilization summary: --------------------------- Selected Device : 2s100etq144-6 Number of Slices: 129 out of 1200 10% Number of Slice Flip Flops: 86 out of 2400 3% Number of 4 input LUTs: 169 out of 2400 7% Number of bonded IOBs: 57 out of 102 55% Number of GCLKs: 1 out of 4 25% ========================================================================= TIMING REPORT NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT GENERATED AFTER PLACE-and-ROUTE. Clock Information: ------------------ -----------------------------------+------------------------+-------+ Clock Signal | Clock buffer(FF name) | Load | -----------------------------------+------------------------+-------+ clk | BUFGP | 104 | -----------------------------------+------------------------+-------+ Timing Summary: --------------- Speed Grade: -6 Minimum period: 9.767ns (Maximum Frequency: 102.386MHz) Minimum input arrival time before clock: 10.997ns Maximum output required time after clock: 8.878ns Maximum combinational path delay: 11.292ns Timing Detail: -------------- All values displayed in nanoseconds (ns) ------------------------------------------------------------------------- Timing constraint: Default period analysis for Clock 'clk' Delay: 9.767ns (Levels of Logic = 13) Source: carry_flag_flop (FF) Destination: register_bit9 (FF) Source Clock: clk rising Destination Clock: clk rising Data Path: carry_flag_flop to register_bit9 Gate Net Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- ------------ FDRE:C->Q 4 0.992 1.520 carry_flag_flop (carry_flag_flop) LUT4:I0->O 2 0.468 1.150 condition_met_lut (condition_met) LUT3:I1->O 11 0.468 2.350 normal_count_lut (normal_count) LUT3:I0->O 1 0.468 0.000 value_select_mux0 (pc_value<0>) MUXCY:S->O 1 0.515 0.000 pc_value_muxcy0 (pc_value_carry<0>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy1 (pc_value_carry<1>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy2 (pc_value_carry<2>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy3 (pc_value_carry<3>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy4 (pc_value_carry<4>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy5 (pc_value_carry<5>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy6 (pc_value_carry<6>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy7 (pc_value_carry<7>) MUXCY:CI->O 0 0.058 0.000 pc_value_muxcy8 (pc_value_carry<8>) XORCY:CI->O 2 0.648 0.000 pc_value_xor9 (inc_pc_value<9>) FDRSE:D 0.724 register_bit9 ---------------------------------------- Total 9.767ns (4.747ns logic, 5.020ns route) (48.6% logic, 51.4% route) ------------------------------------------------------------------------- Timing constraint: Default OFFSET IN BEFORE for Clock 'clk' Offset: 10.997ns (Levels of Logic = 14) Source: instruction<14> (PAD) Destination: register_bit9 (FF) Destination Clock: clk rising Data Path: instruction<14> to register_bit9 Gate Net Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- ------------ IBUF:I->O 27 0.797 3.175 instruction_14_IBUF (instruction_14_IBUF) LUT4:I0->O 1 0.468 0.920 move_group_lut (move_group) LUT3:I2->O 11 0.468 2.350 normal_count_lut (normal_count) LUT3:I0->O 1 0.468 0.000 value_select_mux0 (pc_value<0>) MUXCY:S->O 1 0.515 0.000 pc_value_muxcy0 (pc_value_carry<0>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy1 (pc_value_carry<1>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy2 (pc_value_carry<2>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy3 (pc_value_carry<3>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy4 (pc_value_carry<4>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy5 (pc_value_carry<5>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy6 (pc_value_carry<6>) MUXCY:CI->O 1 0.058 0.000 pc_value_muxcy7 (pc_value_carry<7>) MUXCY:CI->O 0 0.058 0.000 pc_value_muxcy8 (pc_value_carry<8>) XORCY:CI->O 2 0.648 0.000 pc_value_xor9 (inc_pc_value<9>) FDRSE:D 0.724 register_bit9 ---------------------------------------- Total 10.997ns (4.552ns logic, 6.445ns route) (41.4% logic, 58.6% route) ------------------------------------------------------------------------- Timing constraint: Default OFFSET OUT AFTER for Clock 'clk' Offset: 8.878ns (Levels of Logic = 2) Source: register_bit70 (RAM) Destination: port_id<7> (PAD) Source Clock: clk rising Data Path: register_bit70 to port_id<7> Gate Net Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- ------------ RAM16X1D:WCLK->DPO 1 1.568 0.920 register_bit70 (sy<7>) LUT3:I2->O 3 0.468 1.320 operand_select_mux7 (port_id_7_OBUF) OBUF:I->O 4.602 port_id_7_OBUF (port_id<7>) ---------------------------------------- Total 8.878ns (6.638ns logic, 2.240ns route) (74.8% logic, 25.2% route) ------------------------------------------------------------------------- Timing constraint: Default path analysis Delay: 11.292ns (Levels of Logic = 4) Source: instruction<4> (PAD) Destination: port_id<7> (PAD) Data Path: instruction<4> to port_id<7> Gate Net Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- ------------ IBUF:I->O 10 0.797 2.250 instruction_4_IBUF (instruction_4_IBUF) RAM16X1D:DPRA0->DPO 1 0.935 0.920 register_bit00 (sy<0>) LUT3:I2->O 3 0.468 1.320 operand_select_mux0 (port_id_0_OBUF) OBUF:I->O 4.602 port_id_0_OBUF (port_id<0>) ---------------------------------------- Total 11.292ns (6.802ns logic, 4.490ns route) (60.2% logic, 39.8% route)Article: 75024
I am working on an instrument that currently uses a 300 MHz TI dual- issue DSP + A/Ds + a micro. Under "normal" use, I can get a week out of the D-cell batteries the device uses. At the moment, I am considering replacing the DSP and other glue with an FPGA, but I don't see many low-power options. Any suggestions? Any low-power FPGA experiences to share? I asked an Altera FAE and he very rudely answered "Low-power Altera FPGAs aren't on the road map"...yeah and I bet low-power CPLDs (ala MaxII) weren't on the road map until CoolRunner started hurting sales... I'd like to stick with brand A or X since they offer soft core processors. John.
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