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
Amish, Hold PROG_b low until it is time to configure? That holds off configuration until PROG_b is released. AustinArticle: 121601
"Göran Bilski" <goran.bilski@xilinx.com> wrote: >Hi, > >I think it would be hard to find an ARM core that isn't harvard >architecture. I know most CPUs are a Harvard flavour. But there is still a big difference between a true Harvard CPU with seperate memory spaces and a CPU on which they tied code and data together somewhere in the end (usually a cache). A single memory makes life a lot easier and requires a smaller amount memory move instructions Which means it is faster because the code executes faster (less overhead) and there is room for make-life-easy instructions. >Harvard architecture means that the pathways from the CPU are seperate for >instruction and data. >It doesn't mean that the actual memory needs to be two seperate memories. >In fact the common usage is that the memory is the same. The question is, is the latter still a Harvard CPU? I don't think so. >MicroBlaze has stayed with the same ISA and all new features are optional. >You can take object-code from the first version of MicroBlaze and run it the >latest version (and in the future versions). That sounds just like an ARM. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 121602
YUAN, Nan wrote:
(snip)
> There're serveral binary tricks to get number of bit "1" in a word,
> take C code of 32-bit word for example, there's only 5 summations
> instead of 32.
> unsigned int bitcount32(unsigned int x)
> {
> x = (x & 0x55555555UL) + ((x >> 1) & 0x55555555UL); // 0-2 in 2
> bits
> x = (x & 0x33333333UL) + ((x >> 2) & 0x33333333UL); // 0-4 in 4
> bits
> #if 1
(snip)
> #else
> // Version 2
> x = (x + (x >> 4)) & 0x0f0f0f0fUL; // 0-8 in 4 bits
> x += x >> 8; // 0-16 in 8 bits
> x += x >> 16; // 0-32 in 8 bits
> return x & 0xff;
> #endif
But note that you do a lot more arithmetic than is needed.
This takes advantage of the availability of a 32 bit ALU.
You do five 32 bit additions with carry, and four 32 bit AND
operations.
The hardware implementation using carry save adders is much more
efficient, in terms of both logic and speed.
11 full adders for the first level, eight for the second level,
five for the third level, four for the fourth level, three
for the fifth level, three for the sixth level, two each for
the seventh and eighth level, and one final OR gate. If I
counted right. No carry logic is needed.
Some can be half adders for ASIC, and there might be some
other changes to make optimal use of FPGA LUTs.
-- glen
Article: 121603comp.arch.fpga wrote: > On 28 Jun., 15:40, Terje Mathisen <terje.mathi...@hda.hydro.com> > wrote: >>A few layers of full adders to reduce the 256 input lines into a more >>reasonable number, then one or more carry-save accumulators to gather >>these into something that can be handled very quickly. >> Only when reading out the number of errors do you propagate >> the carries to generate the final/real counts. That is an interesting idea... > In Virtex-5 the 6-LUTs point to a 6-to-3 reduction instead of > full adders. Last time I did it was in the days of 4-LUTs. Also, I didn't need all the high bits, as I only needed 0, 1, 2, 3, 4 or more as output values. > You can also use BRAMs for an 11 to 4 reduction. > 512 bits at 500MHz might be easier than 256 bits at 1GHz. Or pipeline the reduction stages. You have to be able to go through at least one LUT in a clock cycle, anyway, and the FFs are conveniently positioned after the LUTs. -- glenArticle: 121604
On Jul 9, 3:28 am, vasile <picli...@gmail.com> wrote: > On Jul 8, 10:02 pm, sfield...@base2designs.com wrote: > > > > > On Jul 6, 11:49 pm, vasile <picli...@gmail.com> wrote: > > > > On Jul 2, 2:05 pm, "jjlind...@hotmail.com" <jjlind...@hotmail.com> > > > wrote: > > > > > Hello, I'm trying to decide to use an EPC16 or EPCS64 to program the > > > > Stratix II EP2S601020C3 on my board. Can any comment which method is > > > > better/faster? Altera's development kits are using the EPCS64 so I > > > > leaning that direction. > > > > > Thanks, > > > > joe > > > > The better methode looks M25P64 without any compressed code inside and > > > fastest serial solution. > > > Using another microcontroller just for configuration (and not other > > > purposes) > > > seems to me a weird option even if harware cost less than $2 and > > > programming/debugging/PCB design another $20. > > > > Vasile > > > No more weird than using a dedicated CPLD, which is a popular option > > for configuring an FPGA from parallel NOR flash memory. There is no > > way to directly configure an Altera FPGA from an M25P64 > > Strange. I believed the EPCS64 and M25P64 are pin to pin and > programming algorithm compatible... > > (unlike some > > > Xilinx FPGAs), so I assume that the proposed solution assumes a > > microprocessor with a spare SPI port, or having the microprocessor bit > > bang the flash SPI port. > > Steve- Hide quoted text - > > > - Show quoted text - So now I understand Ben's posting. The EPCS64 and M25P64 are claimed to be entirely compatible. Does anybody have any references for this claim? Why is Altera selling an identical part for 3 times the price? Are other parts in the EPCS series also compatible with ST SPI flash components? Maybe somebody from Altera could comment?Article: 121605
On Jul 9, 6:59 pm, Nial Stewart <n...@nialstewartdevelopments.co.uk> wrote: > Jarek Rozanski wrote: > > Hi, > > > Does anyone have experience with Altium LiveDesign (Xilinx Spartan-3 > > XC3S1000) ? How does it perform with ISE WebPack, are there any odd > > issues with it? Any comment will be appreciated. > > > I would like to use it for my CPU project. Size of FPGA is more than I > > need currently but I don't mind getting bigger device :) > > The Altium tools are all very well in principle, but as soon as you start > working out of their box things can get difficult. > > I presume their IP should plug and play as advertised, but as soon as you > design some custom logic of your own it's a different ball game. > If you get timing/routing/constraint problems you're going to have to > dig into the Altera/Xilinx tools that are running in the background. > > IMHO. > > Nial. I intend to use only ISE WebPack. Altium tools are of no interest for me, only the spartan board. I am interested in this starter kit, because it is well priced and moreover there are not many alternatives on Polish market.Article: 121606
On Jun 7, 1:45 am, Shant <shantchandra...@gmail.com> wrote: > On Jun 5, 4:02 pm, John Williams <jwilli...@itee.uq.edu.au> wrote: > > > > > > > Hi Shant, > > > Shant wrote: > > > My basic version of design has two interconnected microblaze, FSL has > > > been used for interconnection. > > > There is one application on each microblaze such that frist writes to > > > second then the second microblaze sends some data back to the first > > > one. > > > Sounds reasonable. > > > > My problem is that while performing Build all user application, it > > > builds the application present in first microblaze but throws errror > > > while building the application in second microblaze. > > > Details of the error message would be helpful! > > > John > > Hey John, > > Thanks for the reply... > > The problem has been figured out. It was because both the microblazes > were using the same Uartlite for their printf function. After removing > the printf from the second microblaze, the build process does not > error out. > > Thanks again. > > Shant- Hide quoted text - > > - Show quoted text - I had a similar problem using printf on MicroBlazes. I would definitely just use the smaller xil_printf instead for MicroBlazes. It also reduces the size of the program (stdio versus iostream) significantly (since we're talking limited local BRAM), which can be helpful. I also had issues where several MBs were sending data to stdout at the same time, and it's pretty funny to see two messages combined into one when they both use the same UART. Well, it's funny now. It wasn't quite so funny at the time. :)Article: 121607
Nico Coesel wrote: > > And why not use an ARM core? That would have made a lot more sense > than creating something completely new. You can, it's just larger and slower. So it's the designer's call. Which would you choose ? - A slower/larger core, with a license fee hit, or a smaller/faster one, FPGA optimised, and license-free on the silicon. The Lattice Mico32 is free, if you want that option. Actel are offering two ARM flavours, and like NIOS I/II the ARM7/Cortex M3 are not object/binary compatibe, but need a recompile and asm-recode. Or, you might choose to not use a FPGA-CPU at all, as the [32 bit + FLASH] offerings become more widespread, and have peripherals the FPGA can only envy. -jgArticle: 121608
On Jul 9, 1:39 pm, austin <aus...@xilinx.com> wrote: > Amish, > > Hold PROG_b low until it is time to configure? That holds off > configuration until PROG_b is released. > > Austin My concern would be what do the DSP and FPGA pins output when they are in reset mode or while programing. It would be an issue if both are driving the address line of the FLASH while one is trying to program itself. AmishArticle: 121609
Amish, While PROG_b is held low, all IO is tristate on the FPGA. Austin axr0284 wrote: > On Jul 9, 1:39 pm, austin <aus...@xilinx.com> wrote: >> Amish, >> >> Hold PROG_b low until it is time to configure? That holds off >> configuration until PROG_b is released. >> >> Austin > > My concern would be what do the DSP and FPGA pins output when they are > in reset mode or while programing. It would be an issue if both are > driving the address line of the FLASH while one is trying to program > itself. > Amish >Article: 121610
hitsx@hit.edu.cn wrote: > To be specific, my program is related to 3D image reconstruction. The > input data is float point numbers in the form of 3D array. I represent > it using symbol: g(x1,y1,z1), while the number of x1,y1,z1 are quite > large. The output data is another 3D float point array. I represent it > using symbol: F(x2,y2,z2), similarily the number of x2,y2,z2 are also > quite large. > The estimated memory usage is 2GB or so, while the calculations > required is listed below: > integer addition 2442 Giga operations per second > float add 814 Giga operations per second > float substrac 2424 Giga operations per second > float muliply 1610 Giga operations per second > float divide 809 Giga operations per second > I want these calculations done in one minite, so we can divide the > operations by 60. > As a matter of fact, if the calculations could be done in 5 minites, > it is OK for me. So for minimum requirment, divide the above numbers > by 300(=60*5). As well as I know image reconstruction, you should be able to do it in fixed point. It is commonly done in floating point for software implementations, but it still might be better to use fixed point for a hardware implementation. Also, for multiply and divide it makes a big difference if it is multiplied or divided by a constant or variable. You might prescale the floating point data in software before sending it through the FPGA based hardware. I would probably consider 24 bits intermediate data for a 16 bit result. Look for books or papers on systolic array implementations of matrix operations. About how much can you spend on hardware? hundreds, thousands, or millions of dollars? -- glenArticle: 121611
I am using Synplicity Synplify Premiere 8.8 and I ran into the problem that it keeps retiming my designs such that a great deal of the logic is placed before the input registers and/or after the output registers. I was clued into this when I went finish implementing the design in ISE and the timing report listed a delay for the input to clock or clock to output (or both) that was longer than the reported minimum period for the design. While looking at timing this close is new to me, I'm guessing the largest of these three values is the fastest that I can clock my design at, barring any multicycle or false paths. Is there any way to constrain Synplify so it won't retime logic outside of the designs main input and output registers? ---Matthew HicksArticle: 121612
Matthew Hicks wrote:
> I am using Synplicity Synplify Premiere 8.8 and I ran into the problem
> that it keeps retiming my designs such that a great deal of the logic is
> placed before the input registers and/or after the output registers. I
> was clued into this when I went finish implementing the design in ISE
> and the timing report listed a delay for the input to clock or clock to
> output (or both) that was longer than the reported minimum period for
> the design. While looking at timing this close is new to me, I'm
> guessing the largest of these three values is the fastest that I can
> clock my design at, barring any multicycle or false paths. Is there any
> way to constrain Synplify so it won't retime logic outside of the
> designs main input and output registers?
Retiming is a synthesis switch.
You can turn it on or off.
But I'm not sure that this is
your problem as retiming will
not move any gates past the first/last flop.
Maybe what you need are some IO timing
constraints for ISE.
-- Mike Treseler
Article: 121613"Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message news:b66e6524a10f8c9905f5bb67596@news.ks.uiuc.edu... >I am using Synplicity Synplify Premiere 8.8 and I ran into the problem that >it keeps retiming my designs such that a great deal of the logic is placed >before the input registers and/or after the output registers. I was clued >into this when I went finish implementing the design in ISE and the timing >report listed a delay for the input to clock or clock to output (or both) >that was longer than the reported minimum period for the design. While >looking at timing this close is new to me, I'm guessing the largest of >these three values is the fastest that I can clock my design at, barring >any multicycle or false paths. Is there any way to constrain Synplify so >it won't retime logic outside of the designs main input and output >registers? > > > ---Matthew Hicks Specify your input and output delay constraints. While I prefer the "OFFSET IN BEFORE" and "OFFSET OUT AFTER" constraints used by Xilinx, the Synplify constraints are the "OFFSET IN AFTER" and "OFFSET OUT BEFORE" style constraints popularized by Synopsys which specify the cycle time from the common clock in the external chip to your FPGA and from the FPGA to the external chip, virtual-clock to virtual-clock. I get around the problem by not using retiming.Article: 121614
> My concern would be what do the DSP and FPGA pins output when they are > in reset mode or while programing. It would be an issue if both are > driving the address line of the FLASH while one is trying to program > itself. > Amish Actually, you're concerned about preventing the FPGA from configuring itself and becoming active too early... Maybe you can have the DSP configure the FPGA : once it has loaded its program from the flash, the DSP can read (at a specific flash address) the FPGA bitstream and send it to the FPGA (via SPI, parallel, whatever). This way you specify where your bitstream is stored in the flash...Article: 121615
On Mon, 09 Jul 2007 23:40:06 +0200, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > hitsx@hit.edu.cn wrote: > >> To be specific, my program is related to 3D image reconstruction. The >> input data is float point numbers in the form of 3D array. I represent >> it using symbol: g(x1,y1,z1), while the number of x1,y1,z1 are quite >> large. The output data is another 3D float point array. I represent it >> using symbol: F(x2,y2,z2), similarily the number of x2,y2,z2 are also >> quite large. > >> The estimated memory usage is 2GB or so, while the calculations >> required is listed below: > >> integer addition 2442 Giga operations per second >> float add 814 Giga operations per second >> float substrac 2424 Giga operations per second >> float muliply 1610 Giga operations per second >> float divide 809 Giga operations per second > You could hack this onto a big GeForce GPU in a standard PC... check out GPGPU.Article: 121616
Thanks, I'll work on applying those constraints tomorrow. For some reason, I thought those constraints were for informational purposes and not something I could use to handcuff the tools. I viewed the informational (sales) items on retiming and they said it doesn't affect the functionality of the design, so I figured a little extra otimazation never hurt. I just didn't think to look at the other timing parameters beside Fmax. Now I know. ---Matthew Hicks > "Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message > news:b66e6524a10f8c9905f5bb67596@news.ks.uiuc.edu... > >> I am using Synplicity Synplify Premiere 8.8 and I ran into the >> problem that it keeps retiming my designs such that a great deal of >> the logic is placed before the input registers and/or after the >> output registers. I was clued into this when I went finish >> implementing the design in ISE and the timing report listed a delay >> for the input to clock or clock to output (or both) that was longer >> than the reported minimum period for the design. While looking at >> timing this close is new to me, I'm guessing the largest of these >> three values is the fastest that I can clock my design at, barring >> any multicycle or false paths. Is there any way to constrain >> Synplify so it won't retime logic outside of the designs main input >> and output registers? >> >> ---Matthew Hicks >> > Specify your input and output delay constraints. > > While I prefer the "OFFSET IN BEFORE" and "OFFSET OUT AFTER" > constraints used by Xilinx, the Synplify constraints are the "OFFSET > IN AFTER" and "OFFSET OUT BEFORE" style constraints popularized by > Synopsys which specify the cycle time from the common clock in the > external chip to your FPGA and from the FPGA to the external chip, > virtual-clock to virtual-clock. > > I get around the problem by not using retiming. >Article: 121617
On Jul 9, 5:21 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > Thanks, I'll work on applying those constraints tomorrow. For some reason, > I thought those constraints were for informational purposes and not something > I could use to handcuff the tools. > > I viewed the informational (sales) items on retiming and they said it doesn't > affect the functionality of the design, so I figured a little extra otimazation > never hurt. I just didn't think to look at the other timing parameters beside > Fmax. Now I know. > > ---Matthew Hicks > > > "Matthew Hicks" <mdhic...@uiuc.edu> wrote in message > >news:b66e6524a10f8c9905f5bb67596@news.ks.uiuc.edu... > > >> I am using Synplicity Synplify Premiere 8.8 and I ran into the > >> problem that it keeps retiming my designs such that a great deal of > >> the logic is placed before the input registers and/or after the > >> output registers. I was clued into this when I went finish > >> implementing the design in ISE and the timing report listed a delay > >> for the input to clock or clock to output (or both) that was longer > >> than the reported minimum period for the design. While looking at > >> timing this close is new to me, I'm guessing the largest of these > >> three values is the fastest that I can clock my design at, barring > >> any multicycle or false paths. Is there any way to constrain > >> Synplify so it won't retime logic outside of the designs main input > >> and output registers? > > >> ---Matthew Hicks > > > Specify your input and output delay constraints. > > > While I prefer the "OFFSET IN BEFORE" and "OFFSET OUT AFTER" > > constraints used by Xilinx, the Synplify constraints are the "OFFSET > > IN AFTER" and "OFFSET OUT BEFORE" style constraints popularized by > > Synopsys which specify the cycle time from the common clock in the > > external chip to your FPGA and from the FPGA to the external chip, > > virtual-clock to virtual-clock. > > > I get around the problem by not using retiming. Retiming will not affect a purely synchronous design's behavior. Do not allow retiming or replication on synchronization registers. That can result in parallel or other improper synchronization problems. Don't ask me how I know... Retiming and replication can be disabled on any register (signal or variable) with a constraint/attribute. I prefer to put such attributes in the source code, since I don't always know up front whether I may need to turn retiming on for the rest of the design. AndyArticle: 121618
On Jul 7, 8:04 pm, JD Newcomb <the.jd.in.sp...@gmail.com> wrote: > Hi, all. > > Can anyone tell me what "Running UPDATE Tcl procedures for OPTION > PLATGEN_SYSLEVEL_UPDATE_PROC..." means, and what platgen actually does > to the .tcl files? > > I'm wondering if this could be the cause of an issue I'm having with > BRAM instances. Before, I could run a Base System with 1 or more > MicroBlazes with any available size Local Memory each, and no other > extra peripherals or software (merely for testing purposes), and it > would build the bitstream just fine. Now, XPS generates this error > with the same Base System straight from the Wizard (ML310 board > v2p30ff896-6, MicroBlaze, 100MHz, no debug, any size Local Memory, no > cache, no FPU, no extra peripherals, no extra software beyond the > bootloop): > > "Mapping design into LUTs... > > ERROR:MapLib:482 - Blockram ramb16_s9_s9_0 is a memory mapped blockram > generated > for the Microprocessor. However it is not connected properly, > causing it to > be trimmed. Please connect up all memory mapped blockram properly > and re-run > Ngdbuild. > etc." > > I'm baffled, as all the system files are the same (MHS, MSS, UCF, XMP, > BMM, etc.) between when my previous working XPS would build a > bitstream and my current broken version of XPS. Thanks to anyone > willing to help me out. > > ----JD---- Yeah, disregard. My script forces the creation of the project files when I should have just let the tools create them. Then everything builds fine. As a friend of mine says, "You gotta feel the Force. Don't force the feel."Article: 121619
Hello all, I m working on an application using DDR SDRAM and i want to simulate (timing simulation) the DDR SDRAM working along with the module i have created. the DDR SDRAM which is implemented on my board (ML300) is Infineon HYB25D256800AT-7. it is implemented as 4 discrete parts each 256Mbit as 8bits*32million = 32MB thus totalling 4*32MB= 128MB. if someone has the model/know a place where i can download VHDL/Verilog simulation model of the above part that will be very useful for my project. Also i have a similar DDR SDRAM simulation model. this part is manufactured by Micron MT46V32M8TG-75 and similar 256Mb 8bits*32mil = 32 MB. is it advisable to use this simulation model in the place of the infineon? the DQ, DQS, DM, ADDR, col are all same for the two. any help in this regard will be very useful. with warm regards, Chakra.Article: 121620
Also i will be using model sim for simulation. regards, Chakra.Article: 121621
Jarek Rozanski wrote: > I intend to use only ISE WebPack. Altium tools are of no interest for > me, only the spartan board. I am interested in this starter kit, > because it is well priced and moreover there are not many alternatives > on Polish market. I don't know about the LiveDesign board, but I know the Nanoboard (NB-1) does not accept a standard Altera programming cable, so you can't simply use Quartus, for example. Not sure about the Xilinx cable though... So you might want to check that you can use the Xilinx programming software directly with the LiveDesign board... Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 121622
To see the problem, I did a simple one cycle divider. To get the maximum frequency for the divider I thought, "I'll just register the inputs and output so the tools can have registers to calculate critical path times between. While synthesizing it, I kept pushing the requested frequency higher. Well, I got it up to 800MHz and thought, "not a chance in..." I looked at the technology schematic and all calculations were being done before the input registers and after the output registers. The critical path was a wire linking the input register to the output register. The minimum input delay before clock was in the hundred nanoseconds range and so was the maximum output delay after clock, but that critical path was sure short. ---Matthew Hicks > Matthew Hicks wrote: > >> I am using Synplicity Synplify Premiere 8.8 and I ran into the >> problem that it keeps retiming my designs such that a great deal of >> the logic is placed before the input registers and/or after the >> output registers. I was clued into this when I went finish >> implementing the design in ISE and the timing report listed a delay >> for the input to clock or clock to output (or both) that was longer >> than the reported minimum period for the design. While looking at >> timing this close is new to me, I'm guessing the largest of these >> three values is the fastest that I can clock my design at, barring >> any multicycle or false paths. Is there any way to constrain >> Synplify so it won't retime logic outside of the designs main input >> and output registers? >> > Retiming is a synthesis switch. > You can turn it on or off. > But I'm not sure that this is > your problem as retiming will > not move any gates past the first/last flop. > Maybe what you need are some IO timing > constraints for ISE. > -- Mike Treseler >Article: 121623
Thanks for the heads up, I will keep that in mind for when I go back to my RA job where we will be dealing heavily with crossing clock domains. As we don't have Synplify in my reasearch group, I will refer to the Xilinx ISE constraints guide for info on how to override the default retiming parameter for specific registers. ---Matthew Hicks > On Jul 9, 5:21 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > >> Thanks, I'll work on applying those constraints tomorrow. For some >> reason, >> I thought those constraints were for informational purposes and not >> something >> I could use to handcuff the tools. >> I viewed the informational (sales) items on retiming and they said it >> doesn't affect the functionality of the design, so I figured a little >> extra otimazation never hurt. I just didn't think to look at the >> other timing parameters beside Fmax. Now I know. >> >> ---Matthew Hicks >> >>> "Matthew Hicks" <mdhic...@uiuc.edu> wrote in message >>> news:b66e6524a10f8c9905f5bb67596@news.ks.uiuc.edu... >>> >>>> I am using Synplicity Synplify Premiere 8.8 and I ran into the >>>> problem that it keeps retiming my designs such that a great deal of >>>> the logic is placed before the input registers and/or after the >>>> output registers. I was clued into this when I went finish >>>> implementing the design in ISE and the timing report listed a delay >>>> for the input to clock or clock to output (or both) that was longer >>>> than the reported minimum period for the design. While looking at >>>> timing this close is new to me, I'm guessing the largest of these >>>> three values is the fastest that I can clock my design at, barring >>>> any multicycle or false paths. Is there any way to constrain >>>> Synplify so it won't retime logic outside of the designs main input >>>> and output registers? >>>> >>>> ---Matthew Hicks >>>> >>> Specify your input and output delay constraints. >>> >>> While I prefer the "OFFSET IN BEFORE" and "OFFSET OUT AFTER" >>> constraints used by Xilinx, the Synplify constraints are the "OFFSET >>> IN AFTER" and "OFFSET OUT BEFORE" style constraints popularized by >>> Synopsys which specify the cycle time from the common clock in the >>> external chip to your FPGA and from the FPGA to the external chip, >>> virtual-clock to virtual-clock. >>> >>> I get around the problem by not using retiming. >>> > Retiming will not affect a purely synchronous design's behavior. > > Do not allow retiming or replication on synchronization registers. > That can result in parallel or other improper synchronization > problems. Don't ask me how I know... > > Retiming and replication can be disabled on any register (signal or > variable) with a constraint/attribute. I prefer to put such attributes > in the source code, since I don't always know up front whether I may > need to turn retiming on for the rest of the design. > > Andy >Article: 121624
On Jul 10, 10:32 am, Mark McDougall <m...@vl.com.au> wrote: > Jarek Rozanski wrote: > > I intend to use only ISE WebPack. Altium tools are of no interest for > > me, only the spartan board. I am interested in this starter kit, > > because it is well priced and moreover there are not many alternatives > > on Polish market. > > I don't know about the LiveDesign board, but I know the Nanoboard (NB-1) > does not accept a standard Altera programming cable, so you can't simply > use Quartus, for example. Not sure about the Xilinx cable though... > > So you might want to check that you can use the Xilinx programming > software directly with the LiveDesign board... > > Regards, > > -- > Mark McDougall, Engineer > Virtual Logic Pty Ltd, <http://www.vl.com.au> > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266 I have the Xilinx LiveDesign Evaluation board from Altium. The included cable works fine with ISE. If you look at the schematics available on the web http://www.altium.com/files/livedesign/LiveDesign_EB_Schematics-xilinx_spartan.pdf you will see that it is ISE compatible with some additional pins for a kind of soft test interface have fun Joel
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