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
John Williams wrote: > Hello Taco, > > taco wrote: >> hello all, >> I'm trying to compile the microblaze-toolchain from source on a 64 bits >> linux system, but got stuck. The source from the petalogix repository >> doesn't compile. a first problem was solved with help of colleague: >> a declaration error in 2 header files of binutils/gas (just wondering if >> this is done on purpose by petalogix..). > > I can assure you the source tarball you found on the PetaLogix website > is the same as was used to build the gcc at that time. It builds fine > on a RHEL/CentOS 3 machine, such as the one I am using right now. > > > Regards, > > John Hello john, are you sure? I just did everything again in a clean directory. Executing do_everything results in: /usr/local/microblaze/microblaze-toolchain-sources/srcs/binutils//gas/config/tc-microblaze.h:63: error: array type has incomplete element type and the compilation stops. The solution is to move the struct relax_type from tc.h to as.h in srcs/binutils/gas and remove the forward declaration from as.h. It's just a simple order, but I assume that this also will not work on a RHEL system without doing this unless your gcc compiler works different. (a colleague running ubuntu had the same problem by the way) After this modification the same script continues but stops again in the gcc phase: mkdir -p -- libgcc mkdir -p -- bs mkdir -p -- libgcc/bs mkdir -p -- m mkdir -p -- libgcc/m mkdir -p -- bs/m mkdir -p -- libgcc/bs/m if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi /usr/local/microblaze/microblaze-toolchain-sources/build/lin/bld_gcc/gcc/xgcc -B/usr/local/microblaze/microblaze-toolchain-sources/build/lin/bld_gcc/gcc/ -B/usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/bin/ -B/usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/lib/ -isystem /usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/include -isystem /usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc -I/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/. -I/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/../include -DL_muldi3 -c /usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/libgcc2.c -o libgcc/./_muldi3.o /usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/libgcc2.c: In function `__muldi3': /usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/libgcc2.c:461: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Well, this one is perhaps more related with the compiler/64 bits environment. so I changed do_all_gcc.csh with the -m32 flags and this gives the already mentioned error (libgcc2.c compilation): /tmp/ccYgSyAu.s: Assembler messages: /tmp/ccYgSyAu.s:124: Error: operand must be absolute in range -2147483648..2147483647, not -1042284544 If you've any idea, that would be very nice. TacoArticle: 124101
richard.melikson@gmail.com wrote: >>> They could be, but that would add latencies to the FIFO that >>> are best avoided. ie why compromise the operation, when a Gray >>> Code design will work better ? >> It's more complicated than that. Running a multi-bit value >> through a synchronizer doesn't work if more than one bit changes. >> Some of the bits might get there in time when others don't. >> >> If the data changes from 000 to 111, you might see >> 001, 010, 100, 011, 101, or 110 for a cycle before >> it settles. (That's assuming it was stable at 000 >> for several cycles and then stays at 111 for several >> cycles.) > > Ah - this is a most important point, I think. So, you imply that if I > want to share a counter between two clock domains, I can so a simple > double FF synchronization on it if it's encoded in Gray, whilst for a > normal counter I need a handshake protocol with a synchronized control > signal ? > I think I understand how this can make things faster. > 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). The point is that whenever you look at the code as it passes from one value to the next, it is either in the old state or in the new state - there is nothing in between. With a binary counter, you could see intermediary stages as different bits toggle with different delays. Synchronisation FF's have nothing to do with it.Article: 124102
Andy wrote: > On Sep 11, 4:42 am, David Brown <da...@westcontrol.removethisbit.com> > wrote: >> Jonathan Kirwan wrote: >> >> <snip huge and informative post> >> >> I hope you copied-and-pasted a lot of that post rather than writing it >> all yourself! >> >> I hadn't thought about using Gray code for communication, but it's a >> really smart idea. Supposing you want to send 10-bit data within a >> 16-bit message. All you need to do to send data "x" is to calculate: >> >> y = toGray16(x << 6) >> >> At the other side, you receive "z". To get your best estimate for the >> original "x", you calculate: >> >> x' = (fromGray16(z) + 0x1f) >> 6 >> xe = z - (x1' << 6) >> >> xe is the Hamming distance between the sent data (assuming the >> corruption is not too bad, obviously) and the received data, while x' is >> the nearest correct code. >> >> mvh., >> >> David > > Does that work? While adjacent binary codes are always represented by > single bit differences in gray, the converse is not true; single bit > changes in gray are not necessarily adjacent codes in binary. > No, it does not work :-( Perhaps something can be made out of the idea, but it's back to the drawing board. > Also, n-count changes in binary code are not necessarily represented > by n-bit changes in gray. > > Andy >Article: 124103
Can it reach 100 DMIPS =A3=BF
I give the cpu 100MHz clk, and use the Fast Core.
There is a program:
void main()
{
while(1)
{
IOWR_ALTERA_AVALON_PIO_DATA(PIO_0_BASE, data++);
}
}
The frequence of change of the outputs can reach 100 MHz?
Article: 124104The one i am using and it is the first book have used to learn VHDL is "VHDL for Designers" from Stefan Sjoholm and Lennart Lindh.Article: 124105
On 11 Sep., 16:07, "Sylvain Munaut <Some...@SomeDomain.com>" <246...@gmail.com> wrote: > Yes the generated timings are miscomputed ... They forgot to take > several thing into account ... > You can modify the _parameters.vhd file yourself and change the value. > There is only > 4 or 5 important ones. > To redure the wtp and wr to their minimum I think you'll have to > modify the _ddr2_controller.vhd file and force them ... > > To understant how to compute the delay, look at their state machine > and how they use the value you specify. > > Sylvain Hello. OK, my target FPGA is the Virtex5 (I forgot to mention that). The designs generated by the core generator are different for Virtex5, Virtex4 and Spartan3. For the Virtex5 I found the timing calculations in the mem_interface_top_V5_ctrl_0.vhd file. There are some deviations between the comments and the code. e.g. for tRP: -- TRP: PRECHARGE->COMMAND interval - 2 constant TRP_CYC : integer := (TRP/CLK_PERIOD) + 1; When I change the calculation for TRP_CYC in the code like this: constant TRP_CYC : integer := (TRP/CLK_PERIOD) - 2; the tRP time will be shorter in the simulation (less clock cycles are used). This seems to be better but I'm not sure about the reason of the original code. Maybe my "corrected" design with the new timing will doesn't work with real hardware. Is there any official information for my problem or has anybody a hint for me? thx DaMicha.Article: 124106
Paul Keinanen wrote: > On Tue, 11 Sep 2007 20:03:33 -0700, Mike Treseler > <mike_treseler@comcast.net> wrote: > > >>CBFalconer wrote: >> >> >>>'synchronously' requires a clock driving everything. Not avail. >> >>That depends on the application. >>When a clock *is* available, the >>state encoding style is irrelevant >>to timing or function. > > > If you have a counter, you usually feed it with a clock :-) > > A ripple counter (7490 style) is more or less useless for decoding > states at high speeds, since the decoding can be done only after the > sum of the flip-flop propagation delays. > > In synchronous counter (such as 74196), each flip-flop "knows" in > advance, if it should change state at the next count pulse, thus the > delay is only as large as the propagation delay of a single FF. Some > gating is required to decide, if the FF should change state at the > next count pulse or not. It gets murkier when you have to allow for finite routing delays, and in the newest FPGAs routing delays can be significant. > Since gating is required anyway for the counting, I don't see the > point of using a Gray sequence instead of a simple 1-2-4-8 weighting. > > For short sequences, the Johnston counter would be ideal, if you need > to decode all states. Yes, Johnson counters can be useful, and can decode glitch-free as well as Gray counters. The simpler D-FF structure of Johnson counters means they can often count faster than other counters. - but they need more registers for a given modulus, so it's a trade-off. -jgArticle: 124107
"Brad Smallridge" <bradsmallridge@dslextreme.com> writes: > How do you get messages from comp.arch.fpga archives? > > Google brings up headings that I may want to read, however, > when I click on those headings I go to the archives that > are listed by year and month. There isn't a clear way > to find the message that I wanted to read. > The way I used to do it is to use the browsers search within the page funciton to find the words I originally told google to look for. Nowadays, if I'm looking for stuff on c.a.f, I use the "Google groups" interface to search for it (adding "group:comp.arch.fpga" to the text I type into the search box, or use the advanced search). I still use GNUS to post though, no pointy-clicky for me :-) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 124108
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:13eebgov3qke76@corp.supernews.com... > Add this: >> my_proc: process (Bus2ip_Clk) >> begin > if( Bus2ip_clk'event and Bus2ip_Clk='1') then >> if (Bus2ip_Addr = X"some address") then >> Bus2ip_Data <= X"FF00FF00"; >> end if; > end if ; >> end process; >> > > Naah, This is better. > my_proc: process (Bus2ip_Clk) > begin if rising_edge(Bus2ip_Clk) then > if (Bus2ip_Addr = X"some address") then > Bus2ip_Data <= X"FF00FF00"; > end if; end if ; > end process; > HTH., Syms.Article: 124109
On 2007-09-11, A.D. <isd_mod@libero.ix> wrote: > 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. If there are no side-effects for reading the bytes, you can just return them all. Not many modern memory architectures are going to run faster by reading anything smaller than a 32-bit word, anyway. You might want to look at the PCI-X docs. My vague recollection is that the pipelining of BE (and a few other signals) changed in PCI-X and there might be something that explains the change so as to enlighten you as to the operation of "old" PCI. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 124110
On 2007-09-10, Daniel S. <digitalmastrmind_no_spam@hotmail.com> wrote: > > I only use primitives for stuff that cannot be inferred. I can send you code that makes a nice fifo out of SRL16s on a Xilinx part (via inference, not with the coregen) and a huge mishmash of flops on an Altera part... If you use 10% of your FPGA you can be content to use perfectly portable source code. If you really need the best speed and density, you're stuck with generated modules that sometimes don't map well to other architectures. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 124111
Hi folks, I have a question regarding the use of the command line quartus programmer tool under Linux. I have been using for a while, and I noticed that this latter one was *very* slow (10x) compared to the GUI version. It seems that the programmer hangs on somthing for 15 secodns or so before actually starting to download the bitstream. Does anybody on this newsgroup knows how to solve this issue ? Thanks in advance, StevenArticle: 124112
Hi all embedded gurus out there,
I am working on an embedded platform using microblaze. I am
trying
to implement an algo, which does a inverse matrix function on the
microblaze (via C) and then port the results back to matlab.
so this is the scenario.
1) matlab generates some numbers, passes them to microblaze via the
UART (ie. PC to UART)
2) microblaze will then generate the matrix, and then calculate its
inverse and do other stuff (dot product of matrices etc etc).
3) microblaze will then send the result back to PC via UART.
Ok..so here's the problem.
the result obtained differs from matlab's result (I coded the same
implementation also in matlab). the result obtained varies up to an
error of 1 decimal place!!!
How I tried to debug
1) step through the C code using the debugger for microblaze. (this
is
very cool tool).
2) at each step of the way, look at how the variables change for each
operation in the C code running on microblaze...and also observe how
the variables change in matlab
this is what I noticed
thinking it was due to matlab processing it in double precision, i
type cast the whole matlab routine in single precision. then I tried
to verify it again in the same way. And I get the same problem :(
can anyone help? As a result of this precision errors, the whole algo
fails to work. I am really not sure which one to trust now.
Would appreciate if anyone can help me on the same. The current
microblaze platform is using hardware FPU.
Chris
Article: 124113Steven Derrien <sderrienREMOVE@irisa.fr> writes: > I have a question regarding the use of the command line quartus > programmer tool under Linux. I have been using for a while, and I > noticed that this latter one was *very* slow (10x) compared to the > GUI version. Might be a shot in the dark, but I've noticed that some of the Altera command line tools have been running at a very low priority. Try to run as: nice -n -20 quartus_pgm ... You probably have to be root in order to do that. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 124114
lexluthor pisze:
>
> Can it reach 100 DMIPS £¿
>
> I give the cpu 100MHz clk, and use the Fast Core.
>
> There is a program:
>
> void main()
> {
> while(1)
> {
> IOWR_ALTERA_AVALON_PIO_DATA(PIO_0_BASE, data++);
> }
> }
>
> The frequence of change of the outputs can reach 100 MHz?
>
No. Take a look over assembler file. It's not a single instruction.
Additionaly NIOS need more than one clk cycle for instruction execution
( or maybe not)
But anyway you can add hardware extension for special request (like
parallel to serial hardware conversion)
Adam
Article: 124115On Sep 12, 5:24 am, Ben Jackson <b...@ben.com> wrote: > On 2007-09-10, Daniel S. <digitalmastrmind_no_s...@hotmail.com> wrote: > > > > > I only use primitives for stuff that cannot be inferred. > > I can send you code that makes a nice fifo out of SRL16s on a Xilinx part > (via inference, not with the coregen) and a huge mishmash of flops on an > Altera part... If you use 10% of your FPGA you can be content to use > perfectly portable source code. If you really need the best speed and > density, you're stuck with generated modules that sometimes don't map > well to other architectures. > > -- > Ben Jackson AD7GD > <b...@ben.com>http://www.ben.com/ I'd be interested in it if you don't mind. KJArticle: 124116
On 11 Sep, 23:12, Mike Treseler <mike_trese...@comcast.net> wrote: > davew wrote: > > 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 strategy for getting more efficiency of usage out of > > these blocks? > > Skip the wizards, write code, use synthesis. > > Quartus synthesis can do 4096x18 in 73728 bits.http://home.comcast.net/~mike_treseler/block_ram.pdfhttp://home.comcast.net/~mike_treseler/block_ram.vhd > > -- Mike Treseler Thanks Mike, perhaps I'm asking a daft question but your example uses 9 M9K blocks of a Stratix III which = 82944 bits or 73728 as you say if you configure the M9K as 4096X2 = 8192 bits. Your example uses all the bits in the block so the utilisation is 100%. My memory only utilises 60% of the bits but it could have been organised differently with a little extra logic - I'm not suggesting that Quartus should be able to work this out though - I don't think it can because it would involve extra gates and the pipeline delays would be different. In my solution, I used 6 M9K blocks configured as 512X18 and multiplexed the outputs (BTW my memory is dual ported). It also required a decoder to provide individual we lines to each of the blocks. In other words it stacked the memory blocks in series rather than in parallel at the expense of the extra logic. I wondered if this was a common way of getting better utilisation or if there was a better way. Have I missed your point though? DaveW.Article: 124117
Hi, I found the pin list, and all pins are named like .ICLK The two pins which have a different name are inputs of two BUFGMUX. It seems to be matching with my ISE warning ( my_clock may have excessive skew because 2 NON-CLK pins failed to route using a CLK template ). But there is something I don't understand.. I used BUFGMUX primitive to avoid clock problems and to keep my_clock on the global clock network. Does it mean that I can't connect a clock on a BUFGMUX input ? so, how can I do to multiplex clocks keeping my_clock on a global clock network to avoid skew problems ? Thanks by advance, Best regards, Michel. On 6 sep, 12:51, Joseph Samson <u...@not.my.company> wrote: > michel.ta...@gmail.com wrote: > > Hi all, > > > I've got a FPGA design with a lot of clocks! > > ISE > > gives me warnings : > > Route:447 - CLK Net : my_clock may have excessive skew because 2 NON- > > CLK pins failed to route using a CLK template. ( I've this warning for > > a lot of others clock generated by combinatorial logics... ) > > > My question is how can I locate the 2 NON-CLK pins > > Use FPGA Editor to open the routed design. > Find the clock net and highlight it. > Press F2, or select Edit -> Properties of Selected Items... > Choose the 'Pins' tab. > You will see a list of all the pins on that net. > Scroll down the list until you find pins that don't have .CLK (or some > variant like .ICLK1 or .CLKA) in their name. > > --- > Joe Samson > Pixel VelocityArticle: 124118
davew wrote: > On 11 Sep, 23:12, Mike Treseler <mike_trese...@comcast.net> wrote: >> Skip the wizards, write code, use synthesis. >> >> Quartus synthesis can do 4096x18 in 73728 bits.http://home.comcast.net/~mike_treseler/block_ram.pdfhttp://home.comcast.net/~mike_treseler/block_ram.vhd >> >> -- Mike Treseler > > I wondered if this was a common way of getting better utilisation or > if there was a better way. > > Have I missed your point though? I guess the main point was that don't use the wizards to generate the memories unless there is no other way (very exotic amount of ports etc.). It's wiser just to let the synthesizer to infer the memories. Then the memories are usually portable to other architectures, and it's easy in the tools to change how the memories are implemented with attributes or synthesis settings. The integrated synhesizers can infer most of the normal memory structures. Synplify seems to be much better figuring out what to infer even from quite convoluted code that does not follow the example templates. --KimArticle: 124119
Taking a guess, it looks like you are using Xilinx, and taking another guess, you may have created your core using the Xilinx Create Peripheral Wizard. If you did, one thing to look out for is the USER_HIGHADDR. Depending on what options you choose int the Peripheral Wizard, in the core wrapper file the USER_HIGHADDR could be being set with the following line (syntax purposefully abbreviated). USER_HIGHADDR : stl := C_BASEADDR or X"000000FF"; Which has the annoying effect of only allowing 256 byte addresses. If you are trying to read an address within your core above xFF, the IPIF returns 0 for you. In my cores, when I see this I always just change this line to read USER_HIGHADDR : stl := C_HIGHADDR; Hope this helps. ErikArticle: 124120
After reading http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/d33ee4b046fdbc83/3c6a335982d8fccd#3c6a335982d8fccd I started to wonder if anyone has attempted to write a book on VHDL design patterns. Or for that matter HDL patterns in general. I guess I am looking for something in the same style as Design Patterns by Gamma and etc, but for hardware.Article: 124121
Hi, Eric Erik Anderson a écrit : > After reading http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/d33ee4b046fdbc83/3c6a335982d8fccd#3c6a335982d8fccd > I started to wonder if anyone has attempted to write a book on VHDL > design patterns. Or for that matter HDL patterns in general. I guess > I am looking for something in the same style as Design Patterns by > Gamma and etc, but for hardware. There's a paper "Design Patterns for Reconfigurable Computing" by Dehon et al. published in 2004 in FCCM, here is a link to a pdf version http://www.cs.caltech.edu/research/ic/pdf/despat_fccm2004.pdf Regards, StevenArticle: 124122
"Eli Bendersky" <eliben@gmail.com> wrote in message news:1189574386.802346.152830@19g2000hsx.googlegroups.com... > On Sep 11, 9:33 pm, n...@puntnl.niks (Nico Coesel) wrote: >> It seems I have misplaced my VHDL book a long time ago and I can't >> figure out where I left it. In short: I need a new VHDL book :-( >> >> Can anyone recommend a good generic VHDL reference? I'm not looking >> for a book with a particular bias towards fpga design, asic design, or >> simulation. >> > > I've waded through my share of VHDL books, and Ashenden's (Designer's > Guide) is by far the best of the pack. > > Eli > I'll second the Ashenden's (Designer's Guide) plug, but also add that I have both the Designer's Guide and "The Student's Guide to VHDL" by Peter Ashenden and I actually prefer the student's guide as it seems to have everything I need without having a lot of extra stuff I never use. And its cheeper too!. DanArticle: 124123
> sensitive to a given address means to me: > --my_proc: process (Bus2ip_Clk) > my_proc: process (Bus2ip_Addr) ?Article: 124124
davew wrote:
> Thanks Mike,
> perhaps I'm asking a daft question but your example uses 9 M9K blocks
> of a Stratix III which = 82944 bits or 73728 as you say if you
> configure the M9K as 4096X2 = 8192 bits.
Note that I didn't configure anything other
than the address and data widths. If I
compiled the same code using ise, some other block sizes
would be used.
> Your example uses all the
> bits in the block so the utilisation is 100%.
Your requirement is slightly over the 11 bit boundary
so I used 12 address lines. You may end up needing
that extra memory anyway.
> My memory only utilises
> 60% of the bits but it could have been organised differently with a
> little extra logic - I'm not suggesting that Quartus should be able to
> work this out though - I don't think it can because it would involve
> extra gates and the pipeline delays would be different.
That would be a custom, device-specific design.
If that's what I wanted to do, I would infer
multiple smaller rams and glue them together
in a wrapper entity.
> In my solution, I used 6 M9K blocks configured as 512X18 and
> multiplexed the outputs (BTW my memory is dual ported). It also
> required a decoder to provide individual we lines to each of the
> blocks. In other words it stacked the memory blocks in series rather
> than in parallel at the expense of the extra logic.
That strikes me as a lot of work to save three blocks.
> I wondered if this was a common way of getting better utilisation or
> if there was a better way.
I leave so much block ram unused, that
the thought never occurred to me.
> Have I missed your point though?
I guess my main point is that I have
a bad attitude about using vendor-specific wizards
when I don't have to.
-- Mike Treseler
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