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
Hello,
Suppose I have a PCIe core in an FPGA on a PCIe card plugged into a modern
PC. What read latency should I expect? How much time is it from when I
submit a request to the PCIe core to read from the PC's main memory to when
I get back the first datum from the PCIe core? How does this compare to
PCI-X?
We're architecting a new system and trying to get typical FPGA-based PCIe
latency values.
Also, we're looking for recommendations for an 8-lane PCIe development/eval
card. Which cards are people using?
Thanks
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 106926So, if I have an internally generated clock from a DCM's fx output, "CLK_FX" feeding a group of registers, which are driving pins, "DATA_OUT<*>" what would you recommend? TIMESPEC "TS_DATA_OUT" FROM "CLK_FX" TO "DATA_OUT" 5 ns; # how about this? Thanks, -Brandon Gabor wrote: > Brandon Jasionowski wrote: > > I have been trying to use an internal clock net in my offset > > constraint, sourced from a DCM instance. This appears to be legal, > > according to the CGD: "OFFSET is used only for padrelated > > signals, and cannot be used to extend the arrival time specification > > method to the > > internal signals in a design. A clock that comes from an internal > > signal is one generated > > from a synch element, like a FF. A clock that comes from a PAD and goes > > through a DLL, > > DCM, clock buffer, or combinatorial logic is supported." > > > > But, this doesn't work for me. If I use the original clock pad in the > > constraint it works. However, these OFFSETS are driven by a DCM FX > > output, so the timing is different from the original. Will ISE infer > > this timing difference? It appears to be unclear to me... > > > > Thanks, > > -Brandon > > Normally ISE will infer the timing difference correctly if there is a > simple relationship (like 1:1) from the external pad frequency to > the internal FX clock frequency. Since the OFFSET is used for > PAD signals, this would make sense, since there would have to > be an assumed phase relationship between the external pad signal > requiring the OFFSET constraint and the internal clock. If the > signals requiring the OFFSET constraint are not externally > generated, it would normally make sense to use a PERIOD or > FROM : TO constraint instead. > > HTH, > GaborArticle: 106927
Hey, when i run a script through FPGA editor i get the following error: setattr comp c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4 ERROR:FPGAEditor:25 - "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1 IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0 IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4" is not a valid value for the Config attribute. BRBCF ILOGIC Failure: INVALID_RB: "IFF1::\#FF" CFG: "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1 IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0 IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4" even when i make this change manually and then save and record this a script and then run it, it gives me that error. So when FPGA editor generates the following statement: setattr comp c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4 and that one is exactly the same as the one in my script then what am i doing wrong??? to get me that answer? Thanks in advance for your help, kind regards, TimArticle: 106928
Use the original clock in your spec; the tools should infer the derived clock properly. I've seen the tool work properly when switching to or from the CLKFX domain internall, I'd be surprised if it didn't do a proper job externally. "Brandon Jasionowski" <killerhertz@gmail.com> wrote in message news:1156256235.404717.265480@i42g2000cwa.googlegroups.com... >I have been trying to use an internal clock net in my offset > constraint, sourced from a DCM instance. This appears to be legal, > according to the CGD: "OFFSET is used only for padrelated > signals, and cannot be used to extend the arrival time specification > method to the > internal signals in a design. A clock that comes from an internal > signal is one generated > from a synch element, like a FF. A clock that comes from a PAD and goes > through a DLL, > DCM, clock buffer, or combinatorial logic is supported." > > But, this doesn't work for me. If I use the original clock pad in the > constraint it works. However, these OFFSETS are driven by a DCM FX > output, so the timing is different from the original. Will ISE infer > this timing difference? It appears to be unclear to me... > > Thanks, > -Brandon >Article: 106929
I don't have an answer, but a suggestion: break the config into its parts. If you set the Config IFF1 in one line and Config INIT_Q4 in another - just one per line - you might find out what "really" fails. If I had to guess I'd think the line length in your command is a problem. Breaking it up eliminates this issue and can let you debug the problem to its core. "yttrium" <yttrium@telenet.be> wrote in message news:%RHGg.127097$YS7.119815@blueberry.telenet-ops.be... > Hey, when i run a script through FPGA editor i get the following error: > > setattr comp > c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) > Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ > IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ > IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4 > ERROR:FPGAEditor:25 - "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1 > IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0 > IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4" is not a > valid value for the Config attribute. BRBCF ILOGIC Failure: INVALID_RB: > "IFF1::\#FF" CFG: "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1 > IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0 > IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4" > > even when i make this change manually and then save and record this a > script and then run it, it gives me that error. So when FPGA editor > generates the following statement: > > setattr comp > c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) > Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ > IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ > IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4 > > and that one is exactly the same as the one in my script then what am i > doing wrong??? to get me that answer? > > Thanks in advance for your help, > > kind regards, > > TimArticle: 106930
Hi everyone.
I was just wondering if someone knew where to find documentation about
the Xilinx Virtual Platform.
I'm interested in writing simulation models for my own cores. Since
those cores have external interface, they can't be autogenerated and
they're critical to my application ... (the code will do nothing
without them).
Currently, I've managed by a few hacks to do pretty much what I
want but I'd like to know if there is any documentation about it ?
Because I didn't find much ;(
Sylvain
Article: 106931"Sylvain Munaut" <tnt-at-246tNt-dot-com@youknowwhattodo.com> schrieb im Newsbeitrag news:44eb5529$0$32429$ba620e4c@news.skynet.be... > Hi everyone. > > I was just wondering if someone knew where to find documentation about > the Xilinx Virtual Platform. > > I'm interested in writing simulation models for my own cores. Since > those cores have external interface, they can't be autogenerated and > they're critical to my application ... (the code will do nothing > without them). > > Currently, I've managed by a few hacks to do pretty much what I > want but I'd like to know if there is any documentation about it ? > Because I didn't find much ;( > > Sylvain no there isnt - thats the reason I working on XSIM the only simulator up today that succesfully runs MicroBlaze uClinux unmofied images is pretty fun to see peripherals like sd card systemace ide disk i2c rtc video display pictiva oled to work from the microblaze simulator :) the plugin API for the XSIM simulator is also available. fully documentated ! Antti PS EDK 811 VP sim does choke on uclinux images ASFAIKArticle: 106932
radarman wrote: >>>Maybe you are right and the core and programs are smaller with Forth, I'll >>>think about it. Really useful is that it is simple to write an interactive >>>read-eval-print loop in Forth (like in Lisp), so that you can program and >>>debug a system over RS232. >>> > > > Simpler solution - have the microcode FSM push the flags to the stack. > It's a simple alteration, and saves a lot of heartache. I have > contemplated even pushing the entire context to the stack, since I can > burst write from the FSM a lot faster than I can with individual > PSH/POP instructions, but I figure that would be overkill. For someone doing a fully custom/own assembler/compiler : The tiniest CPUs do not need a stack, and interupts do not need to be re-entrant, so a faster context switch is to re-map the Registers, Flags (and even PC ? ) onto a different area in BRAM. You can share this resource by INTs re-map top-down, and calls re-map bottom up - with a hardware trap when they collide :) -jgArticle: 106933
Antti Lukats wrote:
> "Sylvain Munaut" <tnt-at-246tNt-dot-com@youknowwhattodo.com> schrieb im
> Newsbeitrag news:44eb5529$0$32429$ba620e4c@news.skynet.be...
>> Hi everyone.
>>
>> I was just wondering if someone knew where to find documentation about
>> the Xilinx Virtual Platform.
>>
>> I'm interested in writing simulation models for my own cores. Since
>> those cores have external interface, they can't be autogenerated and
>> they're critical to my application ... (the code will do nothing
>> without them).
>>
>> Currently, I've managed by a few hacks to do pretty much what I
>> want but I'd like to know if there is any documentation about it ?
>> Because I didn't find much ;(
>>
>> Sylvain
>
> no there isnt - thats the reason I working on XSIM the only simulator up
> today that succesfully runs MicroBlaze uClinux unmofied images
Well, I got it to run ... but I thought there might be a doc to be sure
I was doing it right.
I saw xsim
> is pretty fun to see peripherals like
>
> sd card
> systemace
> ide disk
> i2c rtc
> video display
> pictiva oled
>
> to work from the microblaze simulator :)
>
> the plugin API for the XSIM simulator is also available. fully documentated
> !
Well, I tried to find the link again on xilant.com but I just couldn't ...
And the last time I saw it, it was windows only and I'm a linux guy ...
A shame though because a nice simulator would definitly be useful
Sylvain
Article: 106934
Göran Bilski wrote:
>
> Things to keep in mind is to handle larger arithmetic than 16 bits.
> That will usually introduce some kind of carry bits (stored where?).
> You seems to have a c,z bits somewhere but you will need two versions of
> each instruction, one which uses the carry and one which doesn't
>
> Running more than just simple programs in real-time applications
> requires interrupt support which messes things up considerable in the
> control part of the processor.
>
> Do you consider using only absolute branching or also doing relative
> branching?
>
> If you really are wanting to have a processor which is code efficient,
> you might want to look at a stack machine.
> If I was to create a tiny tiny processor with little area and code
> efficient I would do a stack machine.
> But they are much nastier to program but they can be implemented very
> efficiently.
One stack machine, that is still small, but could help greatly with
software flows (being an already defined std)
is the Instruction List language of IEC 61131-1
http://www.3s-software.com/index.shtml?CoDeSys_IL
and
http://en.wikipedia.org/wiki/Instruction_list
in a 'full' system, this supports many data type sizes, but you could
nominate a single size for this task.
IEC Conventions:
Prefix Meaning
% variable
I Input Location
Q Output Location
M Memory Location
(none) Single Bit default
X Single Bit
B Byte ( 8 bits )
W Word ( 16 bits )
D Double ( 32 bits )
L Long ( 64 bits )
N Nibble ( 4 bits )
Opcode encoding is quite small, and you can see some commonality with
PicoBlaze and Mico8 cores.
You do need to define a memroy-reach limit quite early on any CPU design.
-jg
Article: 106935Ralf Hildebrandt wrote: > jacko wrote: > > in quartus II loading a .hex file into 16 bit rom, would it be little > > endian, or is only low byte filled?? > > I can only speak for MaxPlus+ but there reading Intel hex is non-standard. > > Intel hex has always addresses pointing to 8 bit locations, while the > destination width in MaxPlus changes. (16 bit destinations for 16 bit > wide RAM) > > Intel hex is little endian, while Maxplus reads data in big endian order. > cheers, just wondered, as i like to consider full project task before deciding exact implement. may even use AHDL as its shorter and more sucinct, how custom vlsi is the AHDL? looks good for a verification platform, but must have lang export to CIF and GDSII as eventual goals. hope to get register unit done first http://indi.joox.net cheers jackoArticle: 106936
Sylvain Munaut wrote: > Antti Lukats wrote: > > "Sylvain Munaut" <tnt-at-246tNt-dot-com@youknowwhattodo.com> schrieb im > > Newsbeitrag news:44eb5529$0$32429$ba620e4c@news.skynet.be... > >> Hi everyone. > >> > >> I was just wondering if someone knew where to find documentation about > >> the Xilinx Virtual Platform. > >> > >> I'm interested in writing simulation models for my own cores. Since > >> those cores have external interface, they can't be autogenerated and > >> they're critical to my application ... (the code will do nothing > >> without them). > >> > >> Currently, I've managed by a few hacks to do pretty much what I > >> want but I'd like to know if there is any documentation about it ? > >> Because I didn't find much ;( > >> > >> Sylvain > > > > no there isnt - thats the reason I working on XSIM the only simulator up > > today that succesfully runs MicroBlaze uClinux unmofied images > > Well, I got it to run ... but I thought there might be a doc to be sure > I was doing it right. > > I saw xsim > > > is pretty fun to see peripherals like > > > > sd card > > systemace > > ide disk > > i2c rtc > > video display > > pictiva oled > > > > to work from the microblaze simulator :) > > > > the plugin API for the XSIM simulator is also available. fully documentated > > ! > > Well, I tried to find the link again on xilant.com but I just couldn't ... > > And the last time I saw it, it was windows only and I'm a linux guy ... > A shame though because a nice simulator would definitly be useful > got altera stuff as xilinx seems to send multiple emails welcoming me to the ISE, but never gives up the program. cheersArticle: 106937
Hi handyman, > Has anyone experience with prgramming a serial prom/flash like the EPCS16 > using a 8051 compatible uP. > It looks like srunner C code from Altera has some some useable rutines but > a 8051 device driver and file driver is needed. The file driver is only needed to get the raw binary bytes in on a PC - if running on an 8051 you could just take data from a UART or I2C. The 8051 device driver needs to be hand-rolled - it completely depends on which port pins SDI, SDO, SCK and CS are mapped. The PC version uses the parallel port to do its stuff. This bit should take less than one day to write and debug; the file-I/O completely depends on how you want to feed the actual configuration data to the 8051. Best regards, BenArticle: 106938
> I usually choose to specify it in ps, trying to get a number that leads > to an integer number of ps for the FX period. > For example, if you had 133 MHz as a constraint, use 7497 ps as a > period ... 7497 / 7 * 2 = 2140 ps ... That did it! Thank you, Sylvain. #TIMESPEC "TSCAM2" = PERIOD "cam2_xclk" 40MHz HIGH 50 %; -- errors TIMESPEC "TSCAM2" = PERIOD "cam2_xclk" 24997ps HIGH 50 %; Brad Smallridge aivisionArticle: 106939
Okay here's my problem, My company got a dev board from Avnet with a Xilinx Virtex 4 FX12 FPGA on it. So Xilinx sends us ISE 8.2i to use per our lisense. Avnet sends us EDK 8.1i to use. They won't work together! I get an error everytime I try to start up either XPS or EDK. Avnet says they sent me the most up to date version of the software that they have, and to download EDK 8.2i from the Xilinx website, but I can't find anywhere on their website to acutally download it! Any suggestions? Thanks! WadeArticle: 106940
jacko wrote: > search for MSL16 as a compact example of stack machine, i would use > slightly different ops, and things if i did it. The paper at http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/old/msl16/fccm98_fcpu.pdf says it needs 175 CLBs on a Xlinx FPGA. And http://www.xilinx.com/publications/xcellonline/xcell_48/xc_picoblaze48.htm says that the PicoBlaze needs 76 slices (311 slices, if you add serial ports and timers). I'm not sure if this is valid for every FPGA, but somewhere I've read that 4 slices = 1 CLB, so the MSL16 needs more than 9 times more logic gates than PicoBlaze. This is not my idea of a small core. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106941
This post might not be directly on topic here but I'm hoping that someone else out in FPGA-land might have come across a similar problem. The problem: I'm using an FPGA to do emulation of RTL that would normally be build into an ASIC.As such, therefore, the RTL is not very `FPGA friendly' and I can only get a speed of 33-40MHz, maybe 50 at a push. The trouble is that the system incorporates a DDR DRAM controller and DDR DRAMs have a min. frequency spec - 66MHz in the case of the ones I'm using - related to the internal DLL. I *think* that this is why I'm getting no response from the RAMs during read cycles & the data bus seems to be floating. I've tried running with both DLL enabled and disabled to no avail. [Maybe some manufacturers work in this mode and others don't]. Any ideas ?Article: 106942
r...@mips.com wrote: > This post might not be directly on topic here but I'm hoping that > someone else out in FPGA-land might have come across a similar problem. > > The problem: I'm using an FPGA to do emulation of RTL that would > normally be build into an ASIC.As such, therefore, the RTL is not very > `FPGA friendly' and I can only get a speed of 33-40MHz, maybe 50 at a > push. The trouble is that the system incorporates a DDR DRAM controller > and DDR DRAMs have a min. frequency spec - 66MHz in the case of the > ones I'm using - related to the internal DLL. I *think* that this is > why I'm getting no response from the RAMs during read cycles & the data > bus seems to be floating. > > I've tried running with both DLL enabled and disabled to no avail. > [Maybe some manufacturers work in this mode and others don't]. > > Any ideas ? The spec minimum for DDR is 83.33MHz. I have managed to make some run at 66MHz, but I don't think you'll get them to run lower. You are correct that this is related to the internal DLLs in the DDR. If you can't bump the speed, I can't see that you'll be able to make it work Cheers PeteSArticle: 106943
I've put a new release of HDLmaker on the web, you can get it at http://www.polybus.com/hdlmaker/users_guide/index.htm This release adds preliminary support for Virtex5. It also adds some features for use in generating Verilog leaf files. HDLmaker's primary focus is on generating hierarchical Verilog now it can be used for the leaf modules also. HDLmaker is open source, it's licensed under a BSD style license.Article: 106944
PeteS wrote: > r...@mips.com wrote: > > This post might not be directly on topic here but I'm hoping that > > someone else out in FPGA-land might have come across a similar problem. > > > > The problem: I'm using an FPGA to do emulation of RTL that would > > normally be build into an ASIC.As such, therefore, the RTL is not very > > `FPGA friendly' and I can only get a speed of 33-40MHz, maybe 50 at a > > push. The trouble is that the system incorporates a DDR DRAM controller > > and DDR DRAMs have a min. frequency spec - 66MHz in the case of the > > ones I'm using - related to the internal DLL. I *think* that this is > > why I'm getting no response from the RAMs during read cycles & the data > > bus seems to be floating. > > > > I've tried running with both DLL enabled and disabled to no avail. > > [Maybe some manufacturers work in this mode and others don't]. > > > > Any ideas ? > > The spec minimum for DDR is 83.33MHz. I have managed to make some run > at 66MHz, but I don't think you'll get them to run lower. > > You are correct that this is related to the internal DLLs in the DDR. > > If you can't bump the speed, I can't see that you'll be able to make it > work There are solutions to my problem but, trouble is, I don't really like any of them much: o Run the controller part of the system on a 2x clock. The downside is that this would give overly optimistic performance results. o Run the DRAM clock at 2x and do some sort of conversion between the controller's output and the DRAM control/datapath signals ... Ugly, esp the write path! o Similar to the previous but use ordinary SDR RAMs at 2x to emulate DDR at 1x. RickArticle: 106945
rick@mips.com wrote: > This post might not be directly on topic here but I'm hoping that > someone else out in FPGA-land might have come across a similar problem. > > The problem: I'm using an FPGA to do emulation of RTL that would > normally be build into an ASIC.As such, therefore, the RTL is not very > `FPGA friendly' and I can only get a speed of 33-40MHz, maybe 50 at a > push. The trouble is that the system incorporates a DDR DRAM controller > and DDR DRAMs have a min. frequency spec - 66MHz in the case of the > ones I'm using - related to the internal DLL. I *think* that this is > why I'm getting no response from the RAMs during read cycles & the data > bus seems to be floating. > > I've tried running with both DLL enabled and disabled to no avail. > [Maybe some manufacturers work in this mode and others don't]. > > Any ideas ? > It seems pretty on-topic to me! I can't answer your question directly, but I can think of two things you can do: 1. Add a second (third, 99th, whatever) FPGA to implement a DDR DRAM emulator. If you don't want mere test patterns out of it you'll probably have to back it up with static RAM or something. You'll have the drawback that you're not giving the FPGA the 'real thing', but you'll at least be able to check for gross logic errors and even some glitches. 2. Modify the RTL to be more FPGA friendly, but in a way that allows you to verify top-level equivalence. This is even more remote from the first choice, but it gives you the satisfaction of seeing your stuff actually run DDR DRAM at full speed. I assume that "Get a faster FPGA" has already been explored to it's fullest extent... -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 106946
rick@mips.com wrote: > There are solutions to my problem but, trouble is, I don't really like > any of them much: > > o Run the controller part of the system on a 2x clock. The downside is > that this would give overly optimistic performance results. > > o Run the DRAM clock at 2x and do some sort of conversion between the > controller's output and the DRAM control/datapath signals ... Ugly, esp > the write path! > > o Similar to the previous but use ordinary SDR RAMs at 2x to emulate > DDR at 1x. Is 2 as bad as you think ? - you are only trying to keep the DLLs happy, so a simple scheme that reads-twice, and writes-twice, would get the clock into the DRAM realm, but the data-rate matches the larger system ? -jgArticle: 106947
Jim Granville wrote: > One stack machine, that is still small, but could help greatly with > software flows (being an already defined std) > is the Instruction List language of IEC 61131-1 > > http://www.3s-software.com/index.shtml?CoDeSys_IL > > and > > http://en.wikipedia.org/wiki/Instruction_list This looks very interesting, because every command has only one operand, which make developing the core really easy and leaves much space for addressing modes etc. in an opcode, even with 8 bit opcodes. I'll try to mix this with my last addressing modes. I don't need "call", because this is only a jump, where the return address is stored somewhere (I don't need recursion). 4 bits: instruction lda: load accu sta: store accu or: accu = accu or argument xor: " and: " add: " sub: " cmp: " bcc: branch if carry clear bcs: branch if carry set bne: branch if zero set beq: branch if zero clear jmp: jump inp: read from port or special register (pc, flags, i/o ports, timer etc.) outp: write to port or special register I don't need it, but the last possible instruction could be rti, return from interrupt, which restores pc, accu and the flags, which are saved on interrupt entry. With inp/outp the interrupt address and frequency could be setup. 4 bits: address mode (pc relative, 16 bit argument, doesn't make much sense, so all useful combinations fits in 4 bits) immediate, 8 bit argument immediate, 16 bit argument immediate, no arguments, #0 immediate, no arguments, #1 8 bit transfer width: address, 8 bit argument address, 16 bit argument address, pc relative, 8 bit argument address indirect, 8 bit argument address indirect, 16 bit argument address indirect, pc relative, 8 bit argument 16 bit transfer width: address, 8 bit argument address, 16 bit argument address, pc relative, 8 bit argument address indirect, 8 bit argument address indirect, 16 bit argument address indirect, pc relative, 8 bit argument The "pc relative" address modes adds the argument to the pc to get the value. This can be used for the branches and jumps for short jumps, but as well for using some kind of local variables. Let's try the swap algorithm: ; swap 6 byte source and destination MACs p1: .dw 0 p2: .dw 0 tmp: .db 0 lda #5 sta p1 (pc relative) lda #11 sta p2 (pc relative) loop: lda (p1) (address indirect, pc relative) sta tmp (address, pc relative) lda (p2) (address indirect, pc relative) sta (p1) (address indirect, pc relative) lda tmp (address, pc relative) sta (p2) (address indirect, pc relative) lda p2 (pc relative) sub #1 (one byte, because #1 needs no operand) sta p2 (pc relative) lda p1 (pc relative) sub #1 (one byte, because #1 needs no operand) sta p1 (pc relative) bcc loop (pc relative) 37 bytes This is not as good as my RISC idea (20 bytes), but the code is much better to understand: you need not to think about it when reading and writing it. But maybe this is only because some ages ago I've written some demos and intros on C64 (6502), which uses a similiar instruction set :-) Do you think the core for this design would be smaller than PicoBlaze or my RISC idea? BTW: There are some nice contructs possible for smaller code, like to use some kind of zero-page, like implemented in the 6502, because the lda/sta instructions could be used with 8 bit arguments addresses. But code size and speed is not so important for me, a small core is more important, and maybe easy to write assembler code, to avoid implementing a GCC backend for my CPU. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106948
The Stratix II DSP kits are readily available. These both contain 2x 12-bit, 125MHz A/D and 2x 14-bit 165MHz D/A. The ordering codes for these are: DK-DSP-2S60N Featuring the Stratix II 2S60 part with ~60KLEs, >2.5Mb RAM, 36 DSP Blocks. DK-DSP-2S180N Featuring the Stratix II 2S60 part with ~180KLEs, >9.3Mb RAM, 96 DSP Blocks. Additionally the Cyclone II version with a 2C70 device on it will be shipping shortly (boards are done - just finalizing documentation). The ordering code for this is: DK-DSP-2C70N Regards -Joel- homoalteraiensis wrote: > Is there anybody out having experiences with an evaluation board, > containing an Altera FPGA like Cyclone or Stratix and doing Video > processing with it? > > Can anybody recoomend a certain board with a good analog behaviour > (high dynamic ADC) - possibly with a (hard) DSP? > > Thanks in advance.Article: 106949
KJ wrote:
> Daniel O'Connor wrote:
> Many times this symptom is a result of a timing violation. Check that
> the setup time and the clock frequency as reported by the place and
> route timing report is being met by whatever simulation model you have
> driving the design.
Yup, the requirements at the basic level are fairly modest, and my timing
constraints are being met.
> Also, check the list of warnings that pop out of the synthesis to look
> for things that you shouldn't try to do in an FPGA. If you find them,
> you'll probably need to get rid of them. Things like...
> - Transparent latches
> - Generating your own internal clocks (can be done, but only with
> care).
I need to generate an internal clock :(
Any tips on how to do it properly?
Hmm actually I can rejig the design to use an enable which is probably the
right thing to do.
> - Other warnings that pop out should also be perused to make sure you
> understand why it is a warning and if this is a concern in your design.
> As with software, many times a compile time warning is a run time (or
> in your case timing simulation) error.
I have had an odd one which does not appear affect the final result - I have
a right shifter with a lookup table in front (for compatibility reasons) so
I do..
module shifter(DIN, SHIFT, DOUT);
output [15:0] DOUT; // Data out
input [31:0] DIN; // Data in
input [3:0] SHIFT; // Amount to shift by (sort of)
reg [15:0] DOUT;
reg [31:0] TMPOUT;
reg [3:0] SHIFTp;
always @(DIN or SHIFT) begin
case (SHIFT)
4'd13: // 8192 integrations (not possible in the old SA)
SHIFTp = 13;
4'd14: // 16384 integrations (not possible in the old SA)
SHIFTp = 14;
4'd15: // 32768 integrations (not possible in the old SA)
SHIFTp = 15;
4'd12: // 0/1 integrations
SHIFTp = 0;
4'd11: // 2 integrations
SHIFTp = 1;
[...]
endcase // case(SHIFT)
TMPOUT = DIN >> SHIFTp;
DOUT = TMPOUT[15:0];
end // always @ (DIN or SHIFT)
endmodule // shifter
This synthesises to a ROM table and a shifter which is what I want. However
xst warns me that SHIFTp and TMPOUT are assigned but never used. I presume
that it optimised them away or something.
It also complains that SHIFTp is not in the sensitivity list of the always
block.. Seems rather odd to me..
>> Strangely I find that the results are fine but the final FIFO is either
>> not clocking the data in properly, or not clocking it out properly..
>>
> This might be a clue as to where timing is being violated. Since this
> was from an 'old' board I'm guessing that the FIFOs there were the
> garden variety async FIFOs. Hopefully inside the FPGA you didn't try
> to implement that but used a standard synchronous type instead.
Yes they're async - IDT 720x.
I am using the async FIFO core from Xilinx's coregen (and an ALU).
>> However if I test it in isolation it works fine.
> When you're testing it in isolation though I'll bet that the timing in
> and out of the FIFO is not really the same as it is when inside the
> full FPGA. When testing in isolation, if you were to apply stimulus at
> the exact same time to this isolated FIFO it would not work in the same
> manner as you're seeing it not work for you now.
Hmm OK..
What a pain :)
> If it is a synchronous FIFO then are the clocks free running or gated?
> If gated, then how that gating logic is implemented could be the
> problem (once again though, this is just a manifestation of a timing
> failure which can also be caught by full static timing analysis).
It is an async core, although the clock signal is not free running, it is
generated off the card by a PLD which is gating another clock.
Unfortunately I can't change that aspect :(
Based on my reading of the datasheet I don't think that is a problem as such
because the only problem I would have is that the flags won't get updated,
but this design does not use them.
>> I have applied some basic timing constraints, and when looking at the
>> resulting timing diagrams it seems that there is plenty of time for the
>> data to be valid on the input side of the final FIFO before the write
>> clock is applied.
>
> What about all the timing inside of the device though? What is the
> timing report telling you there? If there are multiple clocks involved
> then moving data from one clock domain to the other needs to be done
> properly.
The thing is that the "clocks" aren't free running at all, they're all
derived from the same base clock and gated with a PLD (or 3) and then piped
down the backplane to the card I am designing.
So I think in practise I am not actually going from one clock domain to
another..
I captured some sample signal information and have been using that as my
test suite. In it, the control signals for the final FIFO where I am seeing
the problem the data is clocked in and then clocked out later - at no time
are both sides of the FIFO being clocked..
I'm about to see if there is a way to peer inside the FIFO black box so I
can tell if it's the read or write side that is at issue.
Thanks for your reply!
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
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