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
David Ashley wrote: > Göran Bilski wrote: > >>Doing an "OR" is done like this >> >> MUXCY_I : MUXCY_L >> port map ( >> DI => '1', >> CI => Subtract_carry_out, >> S => Inverted signal_to_or_with, >> LO => oring_result); >> >>Here the oring result is high if either the subtract_carry_out is high >>or the inverted signal_to_or_with is high. > > > Why is the inverter needed, can't you just switch the order of > inputs: > > MUXCY_I : MUXCY_L > port map ( > DI => Subtract_carry_out, > CI => '1', > S => signal_to_or_with, > LO => oring_result); > > 2nd point, wouldn't the synthesizer be expected to make this > optimization automatically? On the face of it this sounds > like vendor lock-in. If you take advantage of this you're tied > to xilinx parts... > > -Dave > > No, You can't switch the input since the carry-chain has to be maintained. Since the carry in is coming from the subtracter it must entering the CI input. But inverting is not a problem since the S input must be driven from the LUT at the same position as the muxcy. Yes, This is a vendor lock-in but since the OP already used a Xilinx device and wanted help, this can help a lot. All generic stuff usually cost something, the more generic you are the higher the cost is. You can always beat pure RTL with hand-optimization for a particular device. The question is if you can spend the time and if you really want it. I usually start with pure RTL and then handoptimize the critical path or where I can see a much better solution (area-wise) than the synthesize tool. GöranArticle: 109126
ziggy schrieb: > In article <1158770147.385889.73830@m73g2000cwd.googlegroups.com>, > "Antti" <Antti.Lukats@xilant.com> wrote: [snip] > If so, people like me will need to stick to other 'free' cores. Hi ziggy, all people like you can stick to any cores of your liking when doing HDL or FPGA designs as the MicroFpga can *NOT* be used with any kind of HDL flow at all. No synthesis, no place and route! Just take an FPGA and GCC compiler. No FPGA vendor tools involved in the process flow: 1) write your C program 2) compile with GCC 3a) merge ELF or bin into BIT or 3b) download over JTAG or serial 4) your C programs runs in any supported FPGA on any board or hardware it is in. AnttiArticle: 109127
Kevin schrieb: > Johannes, > > Lattice's current software, ispLEVER 6.0 does offer the ability to > reinitialize your memory contents without recompiling your design. > Using the Memory Initialization tool, accessed from the tools menu, a > new, or modified memory file .mem can be written to the designs > database file .ncd. After this is done all that needs to be rerun is > the 'Generate Bitstream Data' process. This feature is only available > for use on memory blocks that are implemented in the devices EBR blocks > and created using the software's IPExpress module generation tool. is the memory init available from commandline also? the GUI tool is known to exist for some time, the commandline bit file merging is far less documented AnttiArticle: 109128
vssumesh schrieb: > Göran Bilski wrote: > Hi Goran, > The combinational logic after the addition includes a saturation logic > which checks the 37 bit and based on that output constant values or if > it is not saturation condition output the accumalated data. The bit > checking operation is AND and OR operation like and 31 to 16 bits and > if it is one based on some other parametrs output the saturated value > etc. So it is a AND,OR array then a decision logic after that a mux. > After all these operations there is a shifting operation which formats > the data to write to RAM locations (There is a special format to write > to the RAM). The saturation operation is based on the addition result. > Is it possible to optimize such an operation as you said if yes please > show me an example how to implement that in HDL. Exactly when will a saturation take place? And how many different saturated values are selected? Maybe you can reveal the RTL of that part? I doubt that it is that much of a trade secret.... I doubt that you gain much in FPGAs, but there is patent by infineon for their tricore-2 ALU. They have a logic path parallel to the ALU that checks whether a saturation will occur via a carry look ahead like structure. Kolja SulimmaArticle: 109129
Hi, When I was donwloading bit files to the target FPGA device, the process ran up to around 95% and error message appeared. I have to close the IMPACT program and re-try again. It worked after several times. This happens everytime I download the bit file for the first time. What is the problem? Please advice. Thanks.Article: 109130
ziggy schrieb: > In article <1158792992.714588.34210@h48g2000cwc.googlegroups.com>, > "Antti" <Antti.Lukats@xilant.com> wrote: > > > David Ashley schrieb: > > > > > Assuming it must be free + open source, does anyone have > > > any recommendations? 32 bit minimum. I was looking > > > at the plasma on opencores. Has anyone done a uclinux > > > port or thought of doing one? Conversely if someone wants > > > a uclinux port to plasma I'll do it for $$$. :) > > > > > > -Dave > > > -- > > > David Ashley http://www.xdr.com/dash > > > Embedded linux, device drivers, system architecture > > David, > > > > how much $$$ are we talking about? > > I am looking for open-source core with uclinux, but OR1K is too large > > > > Antti > > I think the leon3 is smaller then the or1k.. But if im wrong ill be > corrected :) > > its also 'standard' so all the tools/os/etc are out there today. Less > development. well LEON3 single project use license is 20 KUSD and OR1K development is also already commercial both are way too largish when we are looking for minimal FPGA CPU that can boot uClinux. LatticeMico32 is possible the smallest 32Bit RISC that is uClinux capable, but there is not known if there will be any uClinux development done for it. besides the above there are some MIPS like cores that are potential candidates to be ramped up to boot uClinux. but there is still a need for any 'minimal' cross-vendor FPGA CPU that can boot uClinux IMHO AnttiArticle: 109131
Antti wrote: > FPGA is not a MicroController? > ...or is it !? > > MicroFpga makes an FPGA to look like an MCU, and makes it programmable > as it would be a normal MCU without requiring any HDL knowledge or FPGA > implementation tools. > > More details will be available from the product website > http://www.microfpga.com > ..soon Hi Antti, I take it that this is some kind of microblaze derivative, stripping out the Xilinx software flow, and thus making the whole design flow much more simple. I can think of a lot of products where the whole microblaze thing might be overkill (not that I have tried it myself), and this could be a solution. It could also be interesting as a first step to microblaze, and once you get comfortable with the software side of it step to the real version. My questions would be : - is there any external Bus ? - Max ROM/RAM available. - Peripherals : counters, UART, VGA controller, etc I just can't wait till you make the details available at the website. Regards Josep DuranArticle: 109132
the PC market is changing quite fast and I would like to get an update on the question from July ... back then I heard - "Athlon 64 1M cache" is faster than Pentium 4 - "Core 2 duo 4M cache" might be even better Intel Core 2 is available and I would like to know if anyone did really test it? does it help? I heard an announcement of "Core 2 Quadro" but I guess this is quite useless with Xilinx ISE? bye, MichaelArticle: 109133
Sumesh Our products including some Virtex-4 products listed here http://www.enterpoint.co.uk/boardproducts.html. John Adair Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development Board. http://www.enterpoint.co.uk "vssumesh" <vssumesh_asic@yahoo.com> wrote in message news:1158688387.480085.59790@m73g2000cwd.googlegroups.com... > One last comment.... ifound the support from xilinx as very very good > really excellent!!!! > Dont know about altera but i dont think they can match that! > But the related to supply of HW or related stuffs got a very poor > response! > regards > Sumesh >Article: 109134
Austin Lesea schreef: > http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?iLanguageID=1&category=-1212267&sGlobalNavPick=&sSecondaryNavPick= > > How easy is that? > > Austin Not easy enough. I have to register. Karl.Article: 109135
Vasanth Asokan schrieb:
Hi,
> Are the fsl() functions being invoked in the same task (after a context
> switch) or in a different task?
There are two task running: one who invokes the fsl() functions and one
which just spends some CPU time to increment an int value. The latter
task is not necessary, calling sleep() in the task invoking the fsl()
functions leads to similar behaviour because of the context switch to
the idle task.
> If in a different task - are you enabling the MSR APU bits prior to the
> kernel being initialized? Global processor level initialization (such as
> MSR, caches and other core registers) should happen before xilkernel_main().
> This will convey the user's intent regarding the processor state to the
> kernel and ensure that all subsequent task switches get the same MSR value.
Caches are disabled and APU is enabled in main() prior to invoking
xilkernel_main(). The task invoking the fsl() functions is statically
defined in the static_pthread_table.
This is the failing code:
//-----------------------------------------------------------------------------
#include "xmk.h"
#include "xparameters.h"
#include "xbasic_types.h"
#include "xcache_l.h"
#include "xpseudo_asm.h"
#include "stdio.h"
#include "pthread.h"
void enable_APU()
{
Xuint32 msr_value = mfmsr();
msr_value |= XREG_MSR_APU_AVAILABLE;
mtmsr(msr_value);
}
void* busy()
{
int l = 0;
while( l < (2 << 2) )
{
int k = 0;
while( k < (1 << 18) )
k++;
l++;
}
return 0;
}
void* user_main()
{
pthread_t busy_thread;
pthread_create(&busy_thread, 0, busy, 0);
print("PPC_CHAT -- Entering user_main() --\r\n");
// provoke context switch
yield();
enable_APU(); // bit is cleared after context switch!
putfsl(21, 0);
print("Send succeded.\r\n");
volatile int i = -1;
getfsl(i, 0);
xil_printf("Reply: %d\r\n", i);
print("PPC_CHAT -- Exiting user_main() --\r\n");
return 0;
}
int main()
{
XCache_DisableICache();
XCache_DisableDCache();
enable_APU();
// starting kernel
xilkernel_main();
return 0;
}
//-----------------------------------------------------------------------------
Regards,
Andreas
Article: 109136"Antti" <Antti.Lukats@xilant.com> wrote in message news:1158775355.824339.155710@m7g2000cwm.googlegroups.com... > bart schrieb: > >> it's my humble understanding that Mico32 is truly RTL, i.e. we do not >> use any library elements, so it should be portable. (although, of >> course, we'd like for you to buy our chips!) >> rgds, >> Bart Borosky, Lattice, online marketing manager >> > >> > Source yes, but not RTL. My guess it's lots of instantiated primitives, >> > thus not portable. > > Yes it is. > > but it uses verilog at such advanced level that is not supported > by Xilinx XST synthesis, e.g. it is only useable with Synplify > as synthesis tool > I believe they have an OEM agreement with Mentor so Precision should be OK as well (I hope :-) Hans www.ht-lab.com > Antti >Article: 109137
On 20 Sep 2006 13:20:34 -0700, "cathy" <hy34@njit.edu> wrote: >Hello, if my system is organized as the following > > ---------Microblaze-----lmb-----8k BRAM > | > Opb Bus > | > 64k BRAM-----opb bus-----customized circuit > > >I initialized my opb bram with the following sentence. > >But when I do simulation, the above initialization process is very time >consuming. So I am wondering is there an easy way to do the OPBBRAM >initialization at the configuring time? Here's an approach that might work, though I haven't tried locating data this way, only code. You can declare a constant array in your "C" code, preferably in a separate ".h" file, so you can write a script or program to generate it. (I have even used a spreadsheet, written the output as a .csv file, and hand edited the "C" array declaration around the comma separated values) Using "Generate Linker Scripts" in EDK you can generate a new code segment, called "myrom", and map its base address to your OPBRAM. Then you have to persuade the linker to locate that constant array in that segment - XAPP642 and Answer Record 16547 show how to locate code, but it should work for constant data. When you have built the application and generated the sim files, you can check system_init.vhd to see if the expected BRAM is there. - BrianArticle: 109138
Peter Alfke wrote: > OOPS, I forgot to point out that the part number must have ES at the > end of its name, e.g. > XC5VLX30-1FFG324CES. > > ES stands for "Early Silicon". The absence of these two letters would > declare it a "volume production" part (which is not available yet), and > the order would automatically be rejected. > One can never be too precise, especially with computerized order entry. > Peter Alfke > I thought "ES" stood for "Engineering Sample"....learn something new every day... AlanArticle: 109139
Hi, I have a question regarding Xilinx DCM. If a clock signal is generated by DCM (say 2X) and used to drive another clock domain. Is the new domain still “synchronized” with the original clock domains? Do I need to insert synchronization circuit when a signal crossing form 1X domain to 2X domain and vice versa? Thank you in advance. Will G.Article: 109140
Hi, This could be due to one of the following several reasons: 1. Your JTAG cable could be incorrectly fastened to the pins. Try tightening it up. 2. Check if the power source that drives the power to the download setup is stable. Power surges may throw an error. 3. iMPACT does behave strangely sometimes, ie, if your PC enters into an unknown state with the software, it throws up an error. Reinstalling ISE usually solves the problem what was the error that you received anyway? zyan wrote: > Hi, > > When I was donwloading bit files to the target FPGA device, the process ran up to around 95% and error message appeared. I have to close the IMPACT program and re-try again. It worked after several times. This happens everytime I download the bit file for the first time. What is the problem? > > Please advice. Thanks.Article: 109141
Hi, You wont have to insert any sync circuits to the 2X clock domain unless this domain is sampling signals in the 1X domain as well. The DCM should take care of all the syncing with respect to the 1X domain (thats what the DCM is there for). If the 2X domain samples signals in the 1X domain ( and there is no handshaking between the domains) then you may have to use a double sync ( two back to back DFF ). Anonymous via the Cypherpunks Tonga Remailer wrote: > Hi, > > I have a question regarding Xilinx DCM. If a clock signal > is generated by DCM (say 2X) and used to drive > another clock domain. Is the new domain still > "synchronized" with the original clock domains? > Do I need to insert synchronization circuit > when a signal crossing form 1X domain to 2X domain > and vice versa? > > Thank you in advance. > > Will G.Article: 109142
zyan wrote: > I only used DIFF_SSTL18_II_DCI and SSTL18_II_DCI in bank 7. This satisfy the rules. But ISE didn't assign DIFF_SSTL18_II_DCI for the pins. It turned out to assign the default LVCOMS25 on those pin, which had violated the rules. It seems like I was not allowed to specify DIFF_SSTL18_II_DCI. So how should I fix this problem? Thanks. Do you 1) have an OBUFDS driving the two differential pins? 2) have the _P and _N pins in the proper differential pair per available Xilinx IOBs? For any pin, there is at most one other pin that can be used as the other half of the differential pair.Article: 109143
David Ashley wrote: > > You're exactly right. Also DCM -> DCM seems to work ok, however > I'm ignoring the "locked" bit on the 50->100 DCM and the system > only pays attention to the locked bit on the 2nd DCM. This is > probably bad. > > -Dave > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architecture Beware of "locked" bits on the Xilinx DCM's. Once locked, they tend to continue to report locked even if the input clock goes away. You need to look at the "status" outputs to get the whole picture, and note that you must reset the DCM if you want it to attempt re-lock afer lock is lost. In the older parts (Spartan 2) with DLL's, the 2x clock output drives a 1x clock when the DLL is not locked. On those parts I actually use this "feature" to detect lock rather than using the "locked" output of the DLL (they have no status bus). Regards, GaborArticle: 109144
Anonymous via the Cypherpunks Tonga Remailer wrote: > Hi, > > I have a question regarding Xilinx DCM. If a clock signal > is generated by DCM (say 2X) and used to drive > another clock domain. Is the new domain still > "synchronized" with the original clock domains? > Do I need to insert synchronization circuit > when a signal crossing form 1X domain to 2X domain > and vice versa? > > Thank you in advance. > > Will G. This depends on your clock routing and buffering. The 1x and 2x clock outputs (0 phase) at the DCM have coincident rising edges. Thus if your two clock domains use the dedicated global routing resources from both outputs of the same DCM (this may require hand selection for BUFGMUX components to minimize skew), you don't need to re-synch when crossing from one (rising-edge) domain to the other. You should be careful with timing constraints because a PERIOD constraint on the 1x domain would usually indicate that the signal does not need to be stable at the falling edge of the 1x clock where the 2x clock has another opportunity to sample. I usually use a clock enable on the 2x clock domain to ensure that it only samples the 1x signals where the rising edges are coincident. HTH, GaborArticle: 109145
I have a Xilinx EDK based design for a Virtex II Pro using the PowerPC Processor. There are two DCMs in the processor subsystem, as defined by the mhs file. The first one, takes a 10MHz clock from the board and multiplies it by 8 to create an 80 MHz clock that runs all of Processor/PLB/OPB stuff. The second DCM just creates a deskewed, 90-degree-shifted version of that clock, for the DDR SDRAM. I am trying to boost the speed to 100 MHz by changing the multiply factor to 10. I have encountered 2 problems. 1. The 100 MHz clock won't run reliably unless the board is power cycled before loading the FPGA image. I also tried a factor of 20 (200 MHz) and it does the same thing. Any of the three speed clocks (80 MHz, 100MHz, or 200 MHz) will run properly if the board is power cycled and then the FPGA is loaded with the image. However, if the image is reloaded with power on, only the 80 MHz clock will run at the correct speed regardless of what image was loaded first. If the 100 or 200 MHz image is loaded after a different speed clock image, the resulting clock is either wrong or not running at all. In all cases, I bring the clock out to a test pin to verify the speed with a scope. I assume this points to some sort of reset issue with the DCM? 2. If I power cycle to ensure a 100 MHz clock, I can't run any program - the debugger loses contact with the system mmediatlely. At this point, the 80 MHz and 100 MHz designs are exactly the same, except for the multiply factor on the DCM and the obvious clock speed related parameters on the varioius cores (plb-ddr and emc mainly). My program is entirely in BRAM so only that and the UARTlite need to run to at least see 'life' from the program. My reading of the specs and Xilinx docs so far, doesn't indicate there is anything else that would need to change for this to run. I am currently reading those again to see if I've missed anything. The original design was started with the Base System Builder, which didn't allow a processor clock higher than 80 MHz from a 10 MHz input. I guess that might be a clue, but the spec sheets don't indicate such a limitation. I am more of a software guy at this point and new to FPGAs, so any general guidance on proceeding to debug this is appreciated. Any clues or sugggestions?Article: 109146
Thank you very much, Brain. I will try today.Article: 109147
Alan Nishioka wrote: > rickman wrote: > > Currently I wanted to look at how fast it might run if I redid it for a > > current FPGA architecture using synchronous memories. I compiled it > > for a Spartan 3 and got the speed up to 77 MHz using less than 10% of > > an XC3S400 (315 slices). I am not impressed with the speed. I > > expected a much larger increase and had hoped for operation at over 100 > > MHz. I checked the timing analyzer output and the signal paths are > > pretty much what I expected, no oddball logic generation and I got > > carry chains where I wanted them. The slow paths have a few long route > > times, so although it may approach 100 MHz with careful floorplanning, > > I don't think this is worth the effort compared to the >> 100 MHz CPU > > cores you can get from the FPGA vendors. > > This does not surprise me. Xilinx seems to have emphasized size over > speed of Spartan as they update it. It is very difficult to get > Microblaze to run at 100MHz in a Spartan 3E, so 77MHz without trying is > about what I would expect. I see what you mean. I checked the Xilinx site and I was confused thinking that MB would run at higher speeds. They list 100 MHz in the -5 high performance versions while I was running my design in the -4 version. So I guess my performance is not so bad considering that it is not pipelined. Of course with a MISC architecture, it requires more instructions to do the same amount of work as the instructions are not as powerful. I may do some other work to see how practical my CPU design will be in the future. I don't mind doing the leg work to support an FPGA CPU core, but not if it does not have advantages. Right now the only advantage is the size, about 600 LUTs vs. 1300 for MB. I'll need to make sure it will do a decent job of keeping up with the clock.Article: 109148
Steve wrote: > > The 100 MHz clock won't run reliably unless the board is power > cycled before loading the FPGA image. <snip> > > I assume this points to some sort of reset issue with the DCM? > Have a look at Answer Record 11778 Virtex/-E/-II/-II Pro, Spartan-II/-IIE/-3 - Device configures correctly after PROG is pulsed, but DLL/DCM/DCI does not function correctly when reconfigured BrianArticle: 109149
Hi, I wanted to deal with interrupts in Microblaze project. I would like to procesor react to int from swich or a button sending a led blik on GPIO. Can someone tell me how to do it. Thanks Jerzy
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