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
Jock wrote: > Can a Cyclone PLL accept a clipped sine wave with an amplitude of 0.8V - > i.e. what is the maximum rise time on the edge of the PLL clock input? What is wrong with a line receiver to meet the AC voltage specifications ? The 1.5V-IO requires 0.35 and 0.65 times 1.5V as levels. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 75051
Symon wrote: > Simon, > I guess it's been a while since you checked out the quiescent supply > currents for the latest parts? For example, worst case Iccintq for the > smallest V2PRO (XC2VP2) is 300mA. That's about 20 hours on a NiMH D cell. > Typical is 20mA, but no-one would design with typical figures, would they? > BTW, anyone know why there's such a big difference from 'typical' to 'max' > figures? Does it depend on the configuration used in the part? > Cheers, Syms. Yes, the typical figures clock only 15% or so of the available flipflops. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 75052
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:clia4n$pd1$1@news.netpower.no... > [snip long post deleted, check the thread] > I wish you luck with your processor. As I said, I don't think anyone has > problems with your choice of licensing and pricing (although I suspect a GPL > version, perhaps less powerful or less optomised, and a commercial version > would help you get customers and feedback faster). It's just that "open" > means far more than "you get the source with the product" (even the Windows > source is available). > > David Thanks David - I wasnt expecting so understanding comments - yes most of your points are valid - the name openchip - well its just is the name, and when choosing the name I hade no intentions to make all openchip products "open" in that sense that all the ip would would be freely downloadable. The community isnt ready for that yet. I have made free software in the past (search for PIP02 on the google as example) lot of my free (for non commercial) sw has been used to create commercial bundles sold for profit, no one ever contacted me back regarding obtaining the commercial use license at all. So I have learned some lessons. Regarding feedback, again I agree 100% with you it is actually amazing how little feedback comes back. This is true for free products and also for commerical products. If you have a commercial product, and you get no feedback, it doesnt mean that the customers are happy, not at all. They just do not give feedback. The uCLinux platform simulator is downloadable for free, but requires registration to the forum (similar to the uCLinux/NIOS required forum registration at niosforum) - so I know there are at least 25 people registered to gain access to the download. I would have hope maybe 1 feedback, but havent yet received any. In the meanwhile the simulator is booting (almost completly) not only microblaze uclinux but also NIOS II uclinux, but I will have to decide the licensing of it. This simulator is written from scratch fully avoiding any GPLed source code useage. Except that the HDL co-simulation uses iverilog ;) so the the hdl sim is GPLed (also the VPI module for what I will provide the source code freely of course). Thanks again for nice long commentary David! Antti PS testing aeMB and writing NIOX did give me many new knowlege about assembly programming for microblaze/nios architectural differencies etc, so I have gained something already. Quiz: Q: How is it possible that NIOS/e is so small ? A: By using 6 cycle microsequencing and 16 bit ALU and internal datapaths. The answer is my bet, but I am pretty sure that the way it is. NIOS II/e uses 6 clock per cycle, those are requiered to fetch the operands in 16 bit chunks and write them back in 16 bit chunks. 6 clocks. Nice idea :)Article: 75053
John, It's a piece of cake with Perl. I used a text file to hold the text of all the Perl regular expression searches for the opcodes along with bits of Perl source code text to convert that particular opcode into machine code. In the code proper I just read in the text file to an array, and then use the 'eval' instruction to execute the elements of the array. (A big advantage of an interpreted language!) Once I sussed this out, it took me about 2 hours to rewrite my custom assembler; the original version was bug ridden and taking ages. Not bad for a hardware engineer! If you know the processor well, and have used Perl with REs before, you could write one for Picoblaze in a morning, no worries. Cheers, Syms. "John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:clha4r$fd8$1@bunyip.cc.uq.edu.au... > I've never written an assembler, maybe it's time to try! >Article: 75054
Hello: I've created an Altera NIOS II Project. Using the IDE, I've built my main.c which contains the simple Hello World porgram with no errors. The IDE keeps running and generated the following "error" message. Kind Description Resource In Folder Location Error 49 PM - (SEVERE) elf2flash: Boot copier overlaps data in flash[Oct 25, 2004 2] Prototype line 46 Now my real probelm is that I can't get at the output from the compile of main.c. It has flashed by in the C-Build window and that window keeps getting cleared several times in the build process. Does anyone know how to get at build output messages?? GeorgeArticle: 75055
John Williams wrote: > 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! Can you elaborate on what the Microblaze does, with these picoblaze source(s) ? Does it create the sources, or modify 'master copies', prior to assembly ? How much resource does the Microblaze work with, uClinix suggests MBytes of FLASH/DRAM ? Assemblers, expecially ones minus linkers, can have quite small footprints, and there are many examples out there. A good one to start with ( much closer than pearl scripts, but they would be tapped for the opcode info ), would be AS, see http://john.ccac.rwth-aachen.de:8000/as/download.html -jgArticle: 75056
John wrote: > 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. You should clarify how much usage, or up time, each block is expecting. Low power is not a direction FPGAs are heading, see the values in this thread of 20 or 40mA typical, 2.5x multiplier for 85'C Tj (thermal run-away anyone :) Wider supply specs are common in uC, but we may start to see this in FPGA data : they must have some lower RAM_Vcc, which is the Min to keep CONFIG, but at very low/stopped clock speeds, and then the higher operate Vcc. Austin: Any numbers on a Config_Keep Vcc (no Clock), and the Static Icc at that operate point ? This is the same as RUN/IDLE in uC designs. For longest battery life, expect to use a good Low Power uC for operator interface, system management, and run the higher power stuff only when you have to. -jgArticle: 75057
WOW! That is one small CPU. I didn't realize that the pB was that small. I will have to take a look to see why it is so much smaller than a stack machine. Does it include interrupts? I notice that the PacoB uses less FFs, but more LUTs and runs slower than the pB. Have you analyzed it to see how they differ? I belive the source is available on the pB vs. the uB which must be bought, no? Pablo Bleyer Kocik wrote: > > Here 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) -- 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: 75058
Hi Jim, Jim Granville wrote: > John Williams wrote: > >> Mike Peattie wrote: >> >>> I have written an assembler for PicoBlaze (KCPSM3) in Perl. It's working >> >> >> 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! > > Can you elaborate on what the Microblaze does, with these picoblaze > source(s) ? The picoblaze program code, input and output data streams, interrupt and reset signals, are all mapped as virtual files within the uClinux file system. So, on the Microblaze uClinux system, you can just cat a picoblaze hex (or bin) file into /proc/picoblaze0/code, and that reprograms the picoblaze. It's pretty neat, I wrote a paper about it for the Field Programmable Technology (FPT) conference we are hosting here in December (plug plug!) http://icfpt04.itee.uq.edu.au If you're interested in the gory details let me know and I'll send you a preprint. > Does it create the sources, or modify 'master copies', prior to assembly ? Currently I just create bin/hex files of the picoblaze object code on the host, then get them down to microblaze somehow (ftp, http, telnet, whatever). Then, once they are on the microblaze, the program code is just CAT'd into the virtual files like I described above. > How much resource does the Microblaze work with, uClinix > suggests MBytes of FLASH/DRAM ? Recommend bare minimum is 2MB but preferably 4MB or more external RAM. Flash is useful for holding the kernel and filesystem image, and also for persistent storage if you need it (all the standard linux file systems are available, jffs2, fat, ext2/3, whatever you prefer). > Assemblers, expecially ones minus linkers, can have quite small > footprints, and there are many examples out there. > > A good one to start with ( much closer than pearl scripts, but they > would be tapped for the opcode info ), would be AS, see > http://john.ccac.rwth-aachen.de:8000/as/download.html Thanks for the tip. It's a fun architecture - I'd love to get the picoblaze assembler hosted on microblaze. In fact, integrating the assembler into the device driver that handles the interface, you could pipe picoblaze assembly files directly into the virtual file, and it would automatically assemble it, and reprogram the picoblaze - too much fun! :) JohnArticle: 75059
John wrote: > > 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. The Altera guy told you right. The FPGA market is driven by density which requires the latest processing geometries, meaning the smallest. The last generation or two have started to ramp up the quiescent power to a point where there is little chance of having a "low power" FPGA any time in the future. Any new low power devices will only be "low" in relative terms. If you want to consider an FPGA, look to the older families. The Altera ACEX parts are much lower power than the newer stuff, at least when you are not clocking them. You will have to figure out how large your design will be to determine the dynamic power. If there are down times for the FPGA processing, would it be possible to power the FPGA off while keeping the user interface running? The FPGA can be reconfigured very quickly so that the user would not be able to notice it. That is something I am doing on our boards, power to the DSP and power hog FPGA are dropped to put the board in a low power mode where just a power controller MCU and an ACEX FPGA are running. This puts power down to < 10 mW and yet the board can respond to external command to power back up within a few 10's of mS. -- 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: 75060
Hi Symon, Symon wrote: > It's a piece of cake with Perl. I used a text file to hold the text of all > the Perl regular expression searches for the opcodes along with bits of Perl > source code text to convert that particular opcode into machine code. In the > code proper I just read in the text file to an array, and then use the > 'eval' instruction to execute the elements of the array. (A big advantage of > an interpreted language!) Sounds like a good way to go - another feature of perl and similar languages that I like is associative arrays - having arbitrary strings as indices into arrays can sometimes make the world of difference. Cheers, JohnArticle: 75061
smu wrote: > > Hello, > > I am developing a FPGAs (BGA case) board. > > Is it possible to check the connections between two pins on two > different FPGAs with the Boundary scan? > > If so, exists there a tool that is able to make this kind of test using > the board schematic? I recall that Memec was selling a low cost boundary scan tester just for this sort of thing. I don't remember what it was called, or what it cost, but I do remember that "low cost" was getting more expensive. I guess they found that they had to raise prices to make ends meet. This tends to be a low volume business area and so they have to charge higher prices. Too bad there are no open source tools for this. But I have not even found much support from the chip makers in this area. They build boundary scan into their chips and leave the rest to you! The best you can hope for is a BSDL file. -- 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: 75062
Jim, We can keep the memory contents of the 4VLX25 all the way down to where the configuration logic recognizes a power down condition (runs around ~0.6 V). Now, to be sure, we have not characterized everything down that far (0.6V), but we did do all characterization for functionality tests from 1.0V to 1.4V, so we know for sure we are safe inside this region (memory contents stay). If someone had a killer app that needed beaucoup parts, we would consider binning for lower numbers. Some people are considering operating at the 1.2V nominal, and then 'sleeping' at 1.0V. The sleeping is just all clocks stopped (disabled). Static current is about half as much compared to 1.2V. So let us say you were at 100 mA at 1.2V, that takes you down to maybe ~55mA at 1.0V. 60 mA for 10 hours is 600 mA-Hr, which is not so bad from a power point of view in a battery operated device. With the 1V, that is 600mW-Hr. AA NIMH batteries are ~ 2000 mA-Hr (1.2V) which is pretty close to 2000 mW-Hr. So with 6 of these, and a good 90% efficient switching power supply, you could have ~10,000 mW-Hr of power. Given that you have to do something some of the time, you then have to go to full 1.2V ON, and then do something useful. That will then make the power jump up to something a bit larger (depending on what you are doing). Let us suppose you allow yourself 1 ampere in the work hard mode, or 1200 mW per hour when doing something. Then you can figure out how much time you can be doing something, vs sleeping. If it is a handheld SDR radio, there is also a 5W transmitter (typical), so you have another 10,000 mW per hour of talk time (assuming a reasonably efficient transmitter). There is also Vccaux (Iccaux) at 2.5V, and Vcco at ??V to consider as well. Austin Jim Granville wrote: > John wrote: > >> 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. > > > You should clarify how much usage, or up time, each block is expecting. > > Low power is not a direction FPGAs are heading, see the values in this > thread of 20 or 40mA typical, 2.5x multiplier for 85'C Tj > (thermal run-away anyone :) > > Wider supply specs are common in uC, but we may start to see this in > FPGA data : they must have some lower RAM_Vcc, which is the Min to keep > CONFIG, but at very low/stopped clock speeds, and then the > higher operate Vcc. > > Austin: Any numbers on a Config_Keep Vcc (no Clock), and the > Static Icc at that operate point ? > > This is the same as RUN/IDLE in uC designs. > For longest battery life, expect to use a good Low Power uC for operator > interface, system management, and run the higher power stuff only when > you have to. > > -jg >Article: 75063
Hi Ron, First, when you run mk_target_board, with the --epcs parameter, an ASMI component is automatically added to the resulting system. This is the component that should be used in the resulting flash programmer design. If you try to replace it with an EPCS controller component, as it sounds like you have, it may not work. Stick with the ASMI component. Second, when you create your actual design in SOPC Builder and pick your target board up at the top, the EPCS controller in that design will be hard-coded to have the same refdes as the ASMI in the flash programmer design. The refdes is how the tools keep track of flash devices (both CFI and EPCS) between the target board and the actual design. You may give them different base addresses in the two designs, or even name them differently, so the refdes is the one thing that always has to be common. And since a system can have only one EPCS (or ASMI), it forces you to use the same refdes for the one in your real system the one in the target board. Re-generate and recompile your target board this way, then do the same with your actual design after selecting the new target board up at the top. Flash programming should work after that. Regards, -Nathan Knight Altera Corp.Article: 75064
Thanks to all who have posted here, I have read all of the helpful information pointed out on the Xilinx site. Very interesting, and has made me rethink my coding style significantly with regards to the reset signal. JasonArticle: 75065
A question to all who have written a bus interface. Is a finite state machine the best way to implement a bus interface (e.g. ISA, PCI, uController) or does it matter. I have examined a few and almost everyone is a FSM. I haven't written any FSMs to date and was curious if there was a benefit to using an FSM. Does it reduce the logic needed in the design, or does it allow for a faster design? Any comments are appreciated. I have done a few bus interfaces myself, but due to my lack of experience with a FSM I have not their use in the applications. JasonArticle: 75066
Austin Lesea wrote: > Jim, > > We can keep the memory contents of the 4VLX25 all the way down to where > the configuration logic recognizes a power down condition (runs around > ~0.6 V). > > Now, to be sure, we have not characterized everything down that far > (0.6V), but we did do all characterization for functionality tests from > 1.0V to 1.4V, so we know for sure we are safe inside this region (memory > contents stay). If someone had a killer app that needed beaucoup parts, > we would consider binning for lower numbers. > > Some people are considering operating at the 1.2V nominal, and then > 'sleeping' at 1.0V. The sleeping is just all clocks stopped (disabled). > > Static current is about half as much compared to 1.2V. So let us say > you were at 100 mA at 1.2V, that takes you down to maybe ~55mA at 1.0V. Sounds like that could be well worth the effort. ( and maybe even 0.75V ? ) <snip> > > There is also Vccaux (Iccaux) at 2.5V, and Vcco at ??V to consider as well. Only some devices have Vccaux - can that be removed, or does it need to be reduced ? Vcco I presume can be removed on selected banks, if you realled needed to, but the Static Icc on IO cells should be very low, as they are relatively few - correct ? -jgArticle: 75067
John Williams wrote: > Hi Jim, > > Jim Granville wrote: >> Can you elaborate on what the Microblaze does, with these picoblaze >> source(s) ? > > > The picoblaze program code, input and output data streams, interrupt and > reset signals, are all mapped as virtual files within the uClinux file > system. So, on the Microblaze uClinux system, you can just cat a > picoblaze hex (or bin) file into /proc/picoblaze0/code, and that > reprograms the picoblaze. > > It's pretty neat, I wrote a paper about it for the Field Programmable > Technology (FPT) conference we are hosting here in December (plug plug!) > > http://icfpt04.itee.uq.edu.au > > If you're interested in the gory details let me know and I'll send you a > preprint. > >> Does it create the sources, or modify 'master copies', prior to >> assembly ? > > > Currently I just create bin/hex files of the picoblaze object code on > the host, then get them down to microblaze somehow (ftp, http, telnet, > whatever). Then, once they are on the microblaze, the program code is > just CAT'd into the virtual files like I described above. > >> How much resource does the Microblaze work with, uClinix >> suggests MBytes of FLASH/DRAM ? > > > Recommend bare minimum is 2MB but preferably 4MB or more external RAM. > Flash is useful for holding the kernel and filesystem image, and also > for persistent storage if you need it (all the standard linux file > systems are available, jffs2, fat, ext2/3, whatever you prefer). > >> Assemblers, expecially ones minus linkers, can have quite small >> footprints, and there are many examples out there. >> >> A good one to start with ( much closer than pearl scripts, but they >> would be tapped for the opcode info ), would be AS, see >> http://john.ccac.rwth-aachen.de:8000/as/download.html > > > Thanks for the tip. It's a fun architecture - I'd love to get the > picoblaze assembler hosted on microblaze. In fact, integrating the > assembler into the device driver that handles the interface, you could > pipe picoblaze assembly files directly into the virtual file, and it > would automatically assemble it, and reprogram the picoblaze - too much > fun! :) Thanks for the overview - Interesting ideas - I can see version control benefits, and a little core-tolerance in handling ASM files over OBJ(Bin/hex) files. Plus ASM files allows more scope to customise prior to assemble as well as being much easier to trouble shoot! Smallest Assemblers were ~20KB, and current HLL ones are ~ 45KB in EXEs, so that's not too large an overhead in a uClinix space. You probably should look at doing both PicoBlaze and MicroBlaze ASM versions :) - IIRC with the AS assembler, you can choose which variants to build. With some care in neumonics, you could target a PB source code, to either PB or MB ? -jgArticle: 75068
Hi! Having followed the thread from 12-Oct-04, I'm also very interested in the Altium board. A still open question is: can that board be used with the Xilinx tools (ISE, EDK)? I guess the main issue would be: can I use iMPACT to configure the board? Today, Altium have posted a new press release: http://www.altium.nl/corp/media/pdfs/20041025_altium_mr_jtag_cable.pdf it states that the Altium software can now be used with any board (which is the inverse of what I want to know). The press release is mainly about a "universal JTAG interface" which can be seen here: http://www.altium.nl/cgi-bin/viewimage.asp?src=/corp/media/pdfs/20041025_altium_mr_jtag_cable_web.jpg From what I understand, it seems to be a cable with JTAG on one end and a parallel connector on the other end, which can emulate a Xilinx cable as well as an Altera cable. I'm not sure though. Some conclusions (tell me what you think): Altium offers that cable for use with foreign boards and their software. Such a cable is not needed with the Altium board. I assume the Altium board already has that same circuit on it, since there is just one board for Spartan and Cyclone. The cable has a switch. What is it for? To switch between Xilinx and Altera behavior maybe? More important: how does the parallel end of the cable behave? Is it a propriatary interface or does it in fact appear like any regular X or A cable - and does the board do the same? Quoting from Altium's webpage: "The LiveDesign Evaluation Board can be specified with either a high-capacity Altera Cyclone (EP1C12F324C8) or Xilinx Spartan-3 (XC3S400-4FG456C) FPGA device. This versatile development platform not only interacts with Altium's software but can be used directly with FPGA vendor tools as a standard development board with no requirement for additional hardware or accessories." That means to me that I can use it with ISE, right? But if it is that simple, why does Altium proudly anounce that thanks to the new cable any board can be used with their software? If their software handles standard interfaces, people could be using it with any board since long, using a standard cable. Does anyone know more than me? :) DennisArticle: 75069
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:cl8qle$uk8$1@gnus01.u.washington.edu... > I have seen warning messages from > Quartus for FF's that don't have a reset or preset input that the > initial state is not guaranteed. > >> There are some articles regarding sync vs async at >> http://www.sunburst-design.com/papers/ > > -- glen > > Quartus synthesis will take advantage of registers which do not specify a power-up condition in don't care optimizations. Note that this can often result in registers being synthesized away because they are stuck-at in one power-up state, so it is important for designers to read the messages as warnings, not info. The assignment editor allows one to protect a register from this optimization, or specifically give a power-up value to a register or set of registers. Hope this helps. - Subroto Datta Altera Corp.Article: 75070
hmm.. maybe someone adventurous enough is just willing to buy and test the contraption ? ;o) or what about sharing the cost ? if i'm right it's $99 +S/H. I'd be willing to participate if 5 of more people participate. the tester could keep the board, I guess ;o) just a thought... lukasz Kevin Becker wrote: > Hi! Having followed the thread from 12-Oct-04, I'm also very > interested in the Altium board. A still open question is: can that > board be used with the Xilinx tools (ISE, EDK)? I guess the main issue > would be: can I use iMPACT to configure the board? > > Today, Altium have posted a new press release: > http://www.altium.nl/corp/media/pdfs/20041025_altium_mr_jtag_cable.pdf > it states that the Altium software can now be used with any board > (which is the inverse of what I want to know). The press release is > mainly about a "universal JTAG interface" which can be seen here: > http://www.altium.nl/cgi-bin/viewimage.asp?src=/corp/media/pdfs/20041025_altium_mr_jtag_cable_web.jpg > From what I understand, it seems to be a cable with JTAG on one end > and a parallel connector on the other end, which can emulate a Xilinx > cable as well as an Altera cable. I'm not sure though. > > Some conclusions (tell me what you think): Altium offers that cable > for use with foreign boards and their software. Such a cable is not > needed with the Altium board. I assume the Altium board already has > that same circuit on it, since there is just one board for Spartan and > Cyclone. The cable has a switch. What is it for? To switch between > Xilinx and Altera behavior maybe? More important: how does the > parallel end of the cable behave? Is it a propriatary interface or > does it in fact appear like any regular X or A cable - and does the > board do the same? > > Quoting from Altium's webpage: > "The LiveDesign Evaluation Board can be specified with either a > high-capacity Altera Cyclone (EP1C12F324C8) or Xilinx Spartan-3 > (XC3S400-4FG456C) FPGA device. This versatile development platform not > only interacts with Altium's software but can be used directly with > FPGA vendor tools as a standard development board with no requirement > for additional hardware or accessories." > > That means to me that I can use it with ISE, right? But if it is that > simple, why does Altium proudly anounce that thanks to the new cable > any board can be used with their software? If their software handles > standard interfaces, people could be using it with any board since > long, using a standard cable. > > Does anyone know more than me? :) > DennisArticle: 75071
austin wrote: > Pete, > > Got it. > > Will take it from here. > > Thanks. .... >> The ML401 is a cool looking Virtex 4 development board made >> and sold by Xilinx. I should have one on Monday or Tuesday. While we're waiting for the sources, could someone fill me in on the details on the "Evaluation versions of Xilinx tools" mentioned at the button of http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sSecondaryNavPick=Design+Tools&iLanguageID=1&category=&key=HW-V4-ML401-USA&sGlobalNavPick=PRODUCTS&BV_SessionID=@@@@1661231197.1098759200@@@@&BV_EngineID=cccfadcmlffdfmfcflgcefldfhndfnf.0 Ie., what can I do with that and how does it differ from the non-evaluation tools (and from the free WebPACK)? The ML401 is a very impressive kit - IMO it sets a new bar for development kits. Thanks, TommyArticle: 75072
All, After reading and contributing to a few interesting threads recently about PCBs for FPGA designs, I thought I'd post about the technology I've been using for the past 3-4 years. My job involves getting a lot of high density circuitry into a small space, and so awhile back I decided to use microvias (laser drilled vias) to pack more stuff onto my boards. The surprising thing was that the boards worked out cheaper for my application than if I hadn't used this method. I'll explain why, but you might first want to download the picture at http://www.fpga-faq.org/caf_pics/layer_1_2.gif My stackup is ten layers, like this:- 1) signal 2) signal 3) ground 4) signal 5) signal 6) ground 7) signal 8) signal 9) ground 10) signal There are laser drilled microvias between layers 1 and 2. The only other vias are through vias, i.e. from layer 1 through all layers to layer 10. This means there's still only one mechanical drilling process during manufacture. What you can see in the picture you downloaded is how to route out all but four of the signal pins on banks 2 and 3 of a V2PRO in a FG676 package without using any through vias, just microvias between the two layers, blue and light green. The track and gap distance is 4mils or 100um. With this technology you can go 8 rows deep on a 1mm pitch BGA without using through vias. In no particular order, here are the advantages. It's no problem at all to put microvias in a pad. The microvia is just a 2mil deep pit that fills with solder, unlike a through via which must be plugged to stop the solder wicking away. You can use fewer signal layers because the signal paths out from the FPGA aren't baulked by through vias. You can use fewer (or no) power layers because it's possible to fit a lot of bypass caps on the back side of the board from the FPGA, with through vias direct from these to the FPGA power balls. (In the picture you can see the ground (green) balls and Vcco (yellow) balls. By the time this board went out, there were two through vias for each power ball.) With a conventional board, the through vias don't leave space on the backside to fit (m)any caps. You get to have a decent ground plane(s) for your BGA devices, not one turned into Swiss cheese by a myriad through vias. Bye-bye ground bounce. You gain board area all over the back side of the board simply because there's less space used by the vias from the topside. Compared to a through via, the SI of a microvia is much better. After all, it's only 1/30th the length of a through via. The components can be closer together, reducing SI issues. I always follow some rules when routing FPGAs this way. Like these:- Draw lines from the four corner balls to the very centre of the part. Don't let any layer 1 or 2 traces cross these lines, it always seems to screw things up. Be prepared to put much more effort into the PCB. This doesn't work well unless you're prepared to sit down with the layout person and swap pins on the FPGA as you route things up to align with other components on the board. For diff pairs be prepared to swap Ps and Ns. You can fix up the inversion inside the FPGA. The upshot is, for a lot of my applications this saves me 4-6 layers over a conventional board. (For others, it simply makes the job possible!) This more than compensates for the cost of using the laser vias. Also, I don't want to hear about warpage! Although the stack looks asymetrical wrt ground planes, the stack up *is* symmetrical wrt cores and prepreg layers. I've had no problems whatsoever with warpage on 1.6 mm boards of up to 8x6 inches. I'm by no means saying this is the best solution for every board, but it worked really well for me. It's certainly worth asking the PCB fab house about the cost, yield etc. Best, Syms. p.s. I'm glad I'll have microvias when I come to route up this bugger.:- http://direct.xilinx.com/bvdocs/userguides/ug075.pdf page 239 of 262 , FX60, FF672 package! The pads are all over the place.Article: 75073
moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0410250326.74fff416@posting.google.com>...
> Thomas Rudloff <thomasREMOVE_rudloffREMOVE@gmx.net> wrote in message news:<417BA070.3030805@gmx.net>...
> > 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.
>
> in the Xilinx's spartan IIE its possible to associate an internal
> pull-up/pull-down resistor to each of the logic inputs, hence tying
> them to either vcc or gnd in case that they are floating.
>
> But still I would like to thank you for the reference to the TI
> article, I downloaded it and I attend to read it soon.
>
> Thanks again..
> Ragards, Moti.
I have experienced a similar problem with the XC2V6000. To get
repeatable
performance I had to resort to 2-phase clocking for local clocks. I
used Global clock buffers every place that I could. I used one common
master clock with a Global clock buffer. I had to use area_group
placements for modular portions of the logic to ensure close placement
for minimum routing delays. I staggered the delay of the 32 BIT output
bus signals to minimize switching noise. I added maximum skew
constraints on local clocks to 2 nsec. I still get
a problem with a few signals each time that I re-compile and re-route
any change.
Bill
Article: 75074Kevin Becker wrote: > > Hi! Having followed the thread from 12-Oct-04, I'm also very > interested in the Altium board. A still open question is: can that > board be used with the Xilinx tools (ISE, EDK)? I guess the main issue > would be: can I use iMPACT to configure the board? > > Today, Altium have posted a new press release: > http://www.altium.nl/corp/media/pdfs/20041025_altium_mr_jtag_cable.pdf > it states that the Altium software can now be used with any board > (which is the inverse of what I want to know). The press release is > mainly about a "universal JTAG interface" which can be seen here: > http://www.altium.nl/cgi-bin/viewimage.asp?src=/corp/media/pdfs/20041025_altium_mr_jtag_cable_web.jpg > From what I understand, it seems to be a cable with JTAG on one end > and a parallel connector on the other end, which can emulate a Xilinx > cable as well as an Altera cable. I'm not sure though. I thought I had posted in that thread that I found out that this was indeed true. Seems the Xilinx and Altera boards use the same cable. I got this from a Altium rep. I have been assured that these boards will work with the FPGA vendor's tools. In fact, they say the vendor's tools are required because you can't do place and route with the Altium tools. > Some conclusions (tell me what you think): Altium offers that cable > for use with foreign boards and their software. Such a cable is not > needed with the Altium board. I assume the Altium board already has > that same circuit on it, since there is just one board for Spartan and > Cyclone. The cable has a switch. What is it for? To switch between > Xilinx and Altera behavior maybe? More important: how does the > parallel end of the cable behave? Is it a propriatary interface or > does it in fact appear like any regular X or A cable - and does the > board do the same? I'm not sure what you are getting at. The pinout of the board end of the cable is the same for both boards. So both boards will match up with the cable. The JTAG circuitry is just buffers and they are on the board. > Quoting from Altium's webpage: > "The LiveDesign Evaluation Board can be specified with either a > high-capacity Altera Cyclone (EP1C12F324C8) or Xilinx Spartan-3 > (XC3S400-4FG456C) FPGA device. This versatile development platform not > only interacts with Altium's software but can be used directly with > FPGA vendor tools as a standard development board with no requirement > for additional hardware or accessories." > > That means to me that I can use it with ISE, right? But if it is that > simple, why does Altium proudly anounce that thanks to the new cable > any board can be used with their software? If their software handles > standard interfaces, people could be using it with any board since > long, using a standard cable. They are just saying that they support a "standard" JTAG interface, like everyone else does. There are some defacto "standards" for JTAG cable pinouts. TI has one and there is one for the ARM CPUs. My guess is the Altium cable uses the TI pinout since that is only 14 pins vs. 20 for the ARM connector. If you look at the tech ref manual for the nanoBoards, they show a not so wide cable for connecting to user designed boards with JTAG. If someone wants to check it out, I'll buy a board. They are only $99. But I get to keep the board when they are done... :) -- 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 FAX
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