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
On Sep 12, 5:54 pm, Subroto Datta <sda...@altera.com> wrote: > On Sep 11, 8:33 am, davew <David.Wo...@gmail.com> wrote: > > > > > Has anyone else encountered the problem of shape and size of M9K > > blocks (I suppose this applies to other devices also). e.g. if I want > > a 2720X18 memory (48960 bits), the wizard will construct one out of 9 > > 4096X2 memories (82944 bits) which is 60% efficient. > > > Does anyone have a stategy for getting more efficiency of usage out of > > these blocks? > > > I can think of one way (in this example by stacking 6 512X18 blocks > > and using multiplexers and decoders etc.) but perhaps someone has a > > better or more straightforward approach. > > > I'm asking this about SIII because I am quite used to SII M4K and M512 > > blocks which seemed to be a better fit for my designs. > > > Thanks, > > DaveW. > > Hi Dave, > > The memory wizard configures the memories to their maximum depth > because this uses the least logic and runs at the greatest speed(i.e. > minimal decode logic required.) There is a maximum depth parameter in > the Megawizard where the user can enter the maximum configuration > depth for your block. In this case, if you enter 512 it should > configure them as 512x18 and do what you need. > > Hope this helps, > Subroto Datta > Altera Corp. Ah! So that's what that parameter which I have been ignoring is for! Thanks Subroto, that's interesting. I'll try that out tomorrow. Dave.Article: 124151
> That's a primitive, so it should be in the UNISIM library. It's new with > the Virtex-5 (Virtex-4 had a FIFO16). So you might neet to update ISE. > See if you have a fifo36.v in xilinx/verilog/src/unisims. If not you need > to update. > -Kevin Yeah, but I'm trying to fit this code to a Virtex-4 on an ML402 dev board so maybe I'll change the fifo36 back to fifo16. There are two generics on the fifo36 part that don't appear on the fifo16: DO_REG => 1, EN_SYN => FALSE, Brad Smallridge AiVisionArticle: 124152
"A.D." <isd_mod@libero.ix> wrote in message news:q3BFi.111012$U01.922629@twister1.libero.it... > Hi all, > I'm implementing a PCI interface in FPGA, but I'm stuck > trying to figuring out what happens with byte enables in > burst read cycles. Specifications are not clear about this > point, saying that if you perform a burst read, byte > enable are *usually* all active on all cycles. Even figures > always show this situation. This hide the real timing or > behaviour of BEs. I mean: are in general BEs referred > to the data present on the bus in next clock cycle? (BEs > signals are asserted one clock in advance during read > cycles...). Or this happens only on the first data cycle? > > To be more clear, I'll try to draw what I mean... :-) > > This is what specs show for a burst read cycle: > > AD <addr>-----<=0=><=1=><=2=>... > BE <cmd=><=be0==============>... > > But if BE need to change during data phase > will we have something like this: > > AD <addr>-----<=0=><=1=><=2=>... > BE <cmd=><be0><be1><be2><be3>... > > or this: > > AD <addr>-----<=0=><=1=><=2=>... > BE < cmd><be0=====><be1><be2>... > > > Can anybody enlighten me? :-) > Thank you in advance for any answer, and excuse > me for this very specific question and for the > cross post. > > Antonio > > > > Are you trying to design at target interface or a master interface? Assuming that you are designing a target interface (your device returns the read data) for then there are two possibilities: - the act of reading a byte can change the state of your device (read side-effects) - the act of reading a byte does NOT change the state of your device (no read side-effects) If the later case (no read side-effects) then you can IGNORE the byte-enables and return all bytes for every data-phase (this is the tyipical case). An example of a device that has read side-effects would be a device that has a data FIFO rather than a RAM. The act of reading the FIFO removes an entry (thus you have read side-effects). BUT this is a poor example for burst transactions so I doubt that this is applicable to you. But there is one more thing that you should consider. How is the burst read transaction being generated? Generally, reads from a CPU (i.e. by a device driver) do NOT generate burst read transactions (they generate single DWORD reads) even for memory-mapped devices. In other words, drivers don't generally cannot generate Memory Read Line or Memory Read Multiple transactions UNLESS they use platform-specific (chipset-specific) features AND the device is mapped into a PREFETCHABLE memory address range. On the other hand.... if you are building a master interface (a device that initiates read transactions) AND you expect the target device to respect random byte enables in each data-phase of a read burst transaction then you should consider the characteristics of the target device you are addressing. Typically, your device will be reading system memory. In this case the memory will ignore the read byte enables and return all bytes (because it does NOT have read side-effects). If your master device is initating peer-to-peer transactions with a device other than system memory then you study the characteristics of that devie to understand its read behavior. And finally, remember that target devices can simply DISCONNECT after each data-phase and turn a burst transaction into a series of single data-phase transactions. So, even if the master has gone to the lengths of trying to implement use of byte enables in read burst transactions I expect most targets will simple use disconnect to decompose the bust into a series of single data-phase reads so you are UNLIKELY to get any benefit. Bottom line... you are probably worrying about implementing complexity that either doesn't matter, or won't give you the results that you desire. TC ORArticle: 124153
A.D. wrote: > Mark McDougall <markm@vl.com.au> wrote in message > 46e792c1$0$14150$5a62ac22@per-qv1-newsreader-01.iinet.net.au... >> No! They must not changed until the data has been >> transferred for the current phase. >> [...] > > Ok, this is what I undestood at first. But suppose you > want to use BEs for a simple gating of the byte lanes: > you have to do it in a combinational way, or you have > to insert a wait state to latch BEs values and then put > gated data on the bus on the next clock. Am I wrong? > Both these things are quite bad! In the first case you > could obtain long propagation delay, in the second > case you waste 50% of clock cycles! > > Regards, > Antonio > > > > Perhaps you're looking at this the wrong way. Software defines the valid data for each of the bus cycles [when it sets up the data to be transferred] and the hardware takes care of transferring said data. PCI is *already* a hog of bandwidth for it's transaction system - a few more cycles with invalid data on D[x:n] won't really matter. Cheers PeteSArticle: 124154
On 2007-09-13, Mindspring Newsgroups <noone@nowhere.com> wrote: > > If the later case (no read side-effects) then you can IGNORE the > byte-enables and return all bytes for every data-phase (this is the tyipical > case). And if you are the target in this case, you can just align your fifo registers to the PCI bus width to avoid any possible overlap. If you want the possibility of reading them simultaneously, replicate the registers elsewhere in a 32-bit block. Video chips do a lot of this so that when you need to do some operation that sets 3 values, you might find one register word that's the combo of all those three and do the work in a single write. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 124155
On 2007-09-12, lexluthor <hezhikuan2007@gmail.com> wrote:
>
>
> while(1)
> {
> IOWR_ALTERA_AVALON_PIO_DATA(PIO_0_BASE, data++);
> }
>
> The frequence of change of the outputs can reach 100 MHz?
I've not used it, but I think Altera's C2H can take code similar to
that and wrap a custom DMA engine around it automagically. Or so
the FAE said!
--
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/
Article: 124156On Sep 9, 5:14 pm, John Williams <jwilli...@itee.uq.edu.au> wrote: > Hi John, > > johnblake2...@gmail.com wrote: > > I've been struggling for weeks to get sdram to work correctly on a > > newly designed board. I was hoping that someone might have some > > suggestions to help me out with my struggle here. This is what I am > > seeing: > > [snip] > > > > > I'm using XMD to test the memory by sending mwr and mrd commands. > > Since my chip has an 8 bit data bus, when I do a mwr 0x21000000 > > 0x01020304 and watch what happens in chipscope I see the following: > > -The column and row get set correctly for the bank 0, column 0, row > > 0. > > -Four bytes are written sequentially 0x01, 0x02, 0x03, 0x04 and DQM > > is active the entire time. > > -All the timing looks right. > > > When I do a read using mrd 0x21000000 I get back 0x01010101. If I do a > > mwr 0x21000000 0x02030405 (a 32bit write) and then a mrd 0x21000000 I > > will get back 0x02020202. I always get back the first byte that was > > written in the four byte sequence. If I do a mwr 0x21000001 0xFF 1 b > > (8 bit write) and a mrd 0x21000001 1 b then I will get back whatever > > was written to 0x21000000. This behavior is consistent across all > > addresses. > > This sounds a lot like a problem I had last year - double check your > ordering of the address lines out from the SDRAM controller - Xilinx > numbers them backwards from the convention in memory device data sheets. > > See this thread: > > http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/86... > > Regards, > > John Sure enough that was my problem, as soon as I reversed the address lines everything started working as I would expect! Thank you for saving me from spending more time figuring this one out. Now I just need to figure out why it is failing the provided memory test application. For some reason the i variable does not initialize to 0. It initializes to 1023 and then decrements instead of incrementing... I'll need to dig through the archives for this one and then possibly post another message if I can't figure it out. I have optimization turned off, not sure what else is wrong. Thanks again.Article: 124157
On Sep 9, 5:23 pm, Alan Nishioka <a...@nishioka.com> wrote: > On Sep 8, 10:39 am, "johnblake2...@gmail.com" > > <johnblake2...@gmail.com> wrote: > > I've been struggling for weeks to get sdram to work correctly on a > > newly designed board. > ... > > -Is there anyway to see the input from the sdram chip using > > chipscope. I tried to look at the OPB bus but that did not show any > > useful information. It just showed the four same bytes showing up on > > the bus. > > Your reasoning looks sound. It might help to look at the sdram data > pins. > > You can copy opb_sdram (assuming that is what you are using) to you r > local pcores directory and modify it with an extra port to output the > sdram data. Then you can look at it with chipscope_ila. > > Alan Nishioka Thank you for the help, I will definitely try adding a port the next time I need to look at the incoming signals. It seems so simple after someone points it out but I wasn't able to make that connection by myself. There is a lot to learn, sometimes it is overwhelming. Thank you.Article: 124158
Good day Paul,
so which one is the correct one? PC's matlab of xilinx FPU? What
do I make out of the results?
Chris
On Sep 13, 1:48 am, Paul Keinanen <keina...@sci.fi> wrote:
> On Wed, 12 Sep 2007 09:13:48 -0700, chriskoh <chrisde...@yahoo.com>
> wrote:
>
>
>
> >but my question is, the difference in values of the result amount to
> >orders of >0.5 occasionally! Isnt that a bit too much difference in
> >results?
>
> That expectation might be realistic for expression containing only
> multiplications and divisions. However, as soon as the expression
> contains additions of a large and a small value or a subtraction
> between two more or less equal values, the result depends heavily on
> the floating point representation.
>
> What exactly is "single precision floating point" ?
>
> I can think about at least a dozen representations that are using that
> name, in which each representations might return a different result
> with problematic parameters.
>
> Paul
Article: 124159I'm trying to do something I think should be simple. I've seen several posts about building custom jtag programmers using byte blaster emulators or xilinx jdrive software, etc. so I hope somebody has already solved this. I have 4 user I/O pins on my V4FX12 device attached to my JTAG scan chain. I want to drive these lines to reprogram the XCF32P prom which my fpga boots from. I am running Linux on the PPC inside the FX12 so I'm thinking I can just cross compile some existing programmer and replace some low level functions (set tdo, read tdi, set/clear tms). Does anyone have something like this? Or can suggest what programmer code is most likely to work in this application? Thanks, ClarkArticle: 124160
In article <1189648753.153265.145740@d55g2000hsg.googlegroups.com>, chriskoh says... > On Sep 13, 1:48 am, Paul Keinanen <keina...@sci.fi> wrote: > > On Wed, 12 Sep 2007 09:13:48 -0700, chriskoh <chrisde...@yahoo.com> > > wrote: > > > > > > > > >but my question is, the difference in values of the result amount to > > >orders of >0.5 occasionally! Isnt that a bit too much difference in > > >results? > > > > That expectation might be realistic for expression containing only > > multiplications and divisions. However, as soon as the expression > > contains additions of a large and a small value or a subtraction > > between two more or less equal values, the result depends heavily on > > the floating point representation. > > > > What exactly is "single precision floating point" ? > > > > I can think about at least a dozen representations that are using that > > name, in which each representations might return a different result > > with problematic parameters. > > > > Paul > > so which one is the correct one? PC's matlab of xilinx FPU? What > do I make out of the results? Which one works? IE what hapens when you multiply the original matrix by its calculated inverse? Robert -- Posted via a free Usenet account from http://www.teranews.comArticle: 124161
PeteS <axkz70@dsl.pipex.com> wrote in message s-qdnRgwjIWx3HXbRVnytwA@pipex.net... > Perhaps you're looking at this the wrong way. Software > defines the valid data for each of the bus cycles [when > it sets up the data to be transferred] and the hardware > takes care of transferring said data. Yes, I know: it is very unlikely that BEs change during a burst read. But specifications say it is still possible... > PCI is *already* a hog of bandwidth for it's transaction > system - a few more cycles with invalid data on D[x:n] > won't really matter. They matter if you bus power consumption is a concern! :-) A.Article: 124162
Mindspring Newsgroups <noone@nowhere.com> wrote in message 13eh0g4iju9p4fd@corp.supernews.com... > > Bottom line... you are probably worrying about implementing > complexity that either doesn't matter, or won't give you the > results that you desire. There are a number of situation in which you can not neglet BEs, for example when dealing with non-prefetchable devices or when you want to minimize bus power consumption (by minimizing bus switching activity). I was considering also this kind of situations for possible enhancement... In effect my current implementation just ignore BEs! :-) A.Article: 124163
You should try to use Ethereal to watch what really runs on ethernet. http://www.ethereal.com/ VitaArticle: 124164
On Sep 7, 7:54 pm, Peter Alfke <pe...@xilinx.com> wrote: > Hi John. > That's what I suggested in my posting yesterday. > "Great minds think the same way" :-) > Peter Alfke > > On Sep 7, 9:29 am, John Larkin > > > > <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > > On Thu, 6 Sep 2007 17:23:39 -0500, "Dan K" <danielgkNOS...@visi.com> > > wrote: > > > >Using linear adjustable regulators for VCCINT (1.25v), VCCIO (3.3v), and > > >VCCAUX (2.5v). VCCINT and VCCIO are dead on, but VCCAUX is 2.72v, 2.88v, > > >and 2.92v on the 3 boards I grabbed and measured. All boards seem to work > > >just fine. > > > >The regulator output voltage is controlled by just 2 resistors. When I > > >changed one of the resistors to lover the voltage a bit, VCCAUX did not > > >change. This leads me to believe that VCCAUX is somehow being "back" > > >powered from the Xilinx chip. These voltages are present like this before > > >the Xilinx chip has been programmed. I have not removed the regulator to > > >measure current yet. Another thought was to put a shotkey diode between the > > >regulator output and the load to see if the Xilinx really is powering > > >VCCAUX, but I thought I'd post and see if anyone else has come across this > > >issue. Half the I/O banks are 2.5v and half are 3.3v if that makes any > > >difference. > > > >Thanks - Dan > > > Try adding a "dump" resistor from Vccaux to ground, and see if that > > pulls the voltage down. > > > John- Hide quoted text - > > - Show quoted text - I'm curious if the original poster has solved the problem in the indicated way above. I have a design with Stratix II which has the same behaviour. thx, VasileArticle: 124165
Charles, NG wrote: > David Brown wrote: > >> It's even better - with the Gray code, you don't need the FF >> synchronisation at all, as long as you are stepping up or down through >> the codes (it's a different matter for step machines that jump steps). > > IMHO I'd be very wary of this statement (and would be interested to hear > how others see it). I remember looking at metastability tests on > flip-flops many years ago and there are two issues here: > 1) Catching / not catching a state change > 2) Lengthening of the FF switching time when set-up/hold times are not met > > Particularily with 2), the tests I observed back then showed a factor of > three to five times against the specified switching time when > set-up/hold times are met. The higher the capacitive load on the FF the > worse it got. > > So, if you have your two gray counters (one being asynchronous) and feed > them to a comparator which then goes to a Full/Empty flag FF, the timing > of the path asynch_gray_counter -> comparator -> full_or_empty_ff will > not be what your timing analysis said if you actually hit the > meta-stability window. If you are running at max speed, this may well > mean that the set-up/hold times on the full/empty FF input are not met, > effectively meaning that the output of this FF now becomes meta-stable. > > IMHO, the advantage of the Gray-coding is that you are guaranteed not to > observe any intermediate switching states (i.e. point 1 above is > addressed) but I would still synchronise the output to be sure that > metastability is not just propogated down the line and eventually > causing problems at some unexpected circuit node. > > Regards, > Charles Agreed - if you are looking at the gray-coded values from a different clock domain, then the signals are asynchronous and must be treated as such (with meta-stability handling as required). Someone also pointed out that your binary-to-gray coder may also be subject to glitches which could pass through to the output - it must be designed carefully. All in all, I'd prefer to let the development tools produce things like FIFOs - they are going to be smaller, faster and safer than if I tried to hand code them myself. But it's nice to know how they work. mvh., DavidArticle: 124166
"Brad Smallridge" <bradsmallridge@dslextreme.com> writes: > Thanks Martin, > You're welcome! > I found google groops and this seems to search into the archives > without any problem and a nice interface to boot. > > Don't know what c.a.f. stands for. comp.arch.fpga :-) > or how to use GNU, although for > you keyboard guys, I hear it's great. > Gnus is the usenet reader that runs within Emacs - once I'd started using Emacs for writing VHDL I discovered all sorts of other useful tools inside it as well! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 124167
Hello, I know that it is possible to overload operators like 'and', 'or', '+',... by using a function with the name "and", "or", "+",... . Is it also possible to overload the attribute operators like: 'high, 'left, 'low, ..? Is it possible to create your own attributes? best regards, KarelArticle: 124168
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:13ega7ucrfkr521@corp.supernews.com... > Yes, Symon, that's shorter. > Hi Brad, There's a little bit more to it than that. For synthesis, the two forms are identical, I think. However, for simulation, IIRC, the rising_edge form is 'better' because it only triggers when the clock changes from '0' to '1'. The other form triggers when the signal changes from anything, e.g. 'Z' or 'U', to '1'. But it is shorter too! :-) Cheers, Syms.Article: 124169
Hi, I am trying to port my VHDL design code into System Generator "Black Box" with some I/O Buffer instatiated, which is LVDS pad. Where I run through a compilation, the following error appeared: ERROR:NgdBuild:455 - logical net 'hwcosimtoplevel/memory_map/ int_mm_dataina_p_b(4)' has multiple driver(s): pin Q on block hwcosimtoplevel/memory_map/int_mm_dataina_p_b_4 with type FDE, pin PAD on block hwcosimtoplevel/memory_map/int_mm_dataina_p_b(4) with type PAD ERROR:NgdBuild:924 - input pad net 'hwcosimtoplevel/memory_map/ int_mm_dataina_p_b(4)' is driving non-buffer primitives: pin Q on block hwcosimtoplevel/memory_map/int_mm_dataina_p_b_4 with type FDE Anyone have idea about the error? I do not know whether is it caused by the tool that reinstantiate the I/O buffer again to the I/O I have instatiated the buffer. If so, anyone have idea to disable it selectively in the system generator environement.Article: 124170
I ran a few posts on Gray codes in my blog - http://asicdigitaldesign.wordpress.com . you can find some efficient ways to build a direct Gray code counter here (in 3 parts): http://asicdigitaldesign.wordpress.com/2007/05/10/counting-in-gray/ http://asicdigitaldesign.wordpress.com/2007/05/13/counting-in-gray-part-ii-observations/ http://asicdigitaldesign.wordpress.com/2007/05/14/counting-in-gray-part-iii-putting-everything-together/ As for your original FSM related question - you might find this post interesting: http://asicdigitaldesign.wordpress.com/2007/09/04/fsm-state-encoding-more-switching-reduction-tips/ NDArticle: 124171
Hello, I am using the xilinx virtex II development board xupv2p. I have built an expansion board that connects to the high speed expansion port, and delivers information from a camera. In ISE, I have produced what I think is a working piece of vhdl to synchronise the camera data (there will be 2 data sets incoming) to the FPGA clock. What I would like to do is just read out this incoming data so I can check it. My idea was to use a microblaze processor - I will need one to do some processing at a later stage, and just do a printf to write the data to hyper-terminal. I used the create / import peripheral wizard, and have been hacking the user_logic file to incorporate my synchronization design. I am a bit unsure of ports though - do I have any user ports - are these the input pins??? I have altered the UCF file to assign the pins of the expansion port to my inputs in my vhdl file. Should I write this data to a slave register?? Then in my C file, is it just a simple read and printf procedure. Any help / ideas I'd be grateful, Thanks Marc.Article: 124172
A.D. wrote: > Mindspring Newsgroups <noone@nowhere.com> wrote in message > 13eh0g4iju9p4fd@corp.supernews.com... >> Bottom line... you are probably worrying about implementing >> complexity that either doesn't matter, or won't give you the >> results that you desire. > > There are a number of situation in which you can not neglet > BEs, for example when dealing with non-prefetchable devices > or when you want to minimize bus power consumption (by > minimizing bus switching activity). > I was considering also this kind of situations for possible > enhancement... In effect my current implementation just > ignore BEs! :-) > > A. I thought the problem was for BEs during bursts. There are no bursts for non-prefethcable devices.Article: 124173
"Hal Murray" <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote in message news:2q-dnXHQf72ryHXbnZ2dnUVZ_tninZ2d@megapath.net... > > Gray code makes sure you only write something to either the > old address or the new address. You also have to make sure > that the new data doesn't get written to the old address. > (or probably worse, part of the new data gets written > on top of the old data) > > How about > 1: change address > 2: wait for address to settle and data hold time > 3: write new data Hal, If you were using an FPGA to do this you could clock the address out on the rising edge of the clock, the data out on the falling edge. If setup and hold times were met this would get you one write per clock. Nial.Article: 124174
On Sep 12, 7:12 pm, "cpope" <cep...@nc.rr.com> wrote: > I have 4 user I/O pins on my V4FX12 device attached to my JTAG scan chain. I > want to drive these lines to reprogram the XCF32P prom which my fpga boots > from. I am running Linux on the PPC inside the FX12 so I'm thinking I can > just cross compile some existing programmer and replace some low level > functions (set tdo, read tdi, set/clear tms). > > Does anyone have something like this? Or can suggest what programmer code is > most likely to work in this application? That is what xsvf and svf are for http://www.xilinx.com/bvdocs/appnotes/xapp503.pdf You download a little source code from xilinx, modify the low level code to twiddle the tdi, tdi, tms and tck correctly and replay the programming sequence generated by impact. xsvf is simply a binary coded svf to save some space. jdrive is similar software, but much more bloated C++ code. On Altera, you do the same thing with jam player. http://www.altera.com/support/devices/tools/jam/tls-jam.html Alan Nishioka
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