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
edaudio2000@yahoo.co.uk wrote: > > I am not too convinced this was a manufacturing or solder short > problem. > The FPGA chip is fed from a 100mA limited power supply, and cannot > imagine how any combination > of solder shorts would have caused the chip to fuse so solidly > internally. There are failure analysis companies around. We have used maser. You will probably have to send them a good and a bad device plus some socketted fan out pcb. > > In any case, the board had been working for a while when it failed > suddenly during tests. > So I imagine some form of external "spanner in the works" may have > been responsible. > There is a 5V line on the board (high current capacity) but that's > all. > > I suspect an ESD failure might have caused the chip to stop working, > or make some of the I/O pins > become not operational, that's all. Curve tracing supplies and signals will show which if any pins have been damaged by ESD. > > The puzzle is that the chip went "fused short" i.e. less than an ohm > between the 3v3 vccio4 and gnd (The 1V5 supply is OK). > > And quite a solid short it is, If I apply 1V to vccio the chip draws > a lot of current and gets warm.. Diagnosing to an on device issue can be done by removing the package surface exposing the passivation layer of the silicon. Cove the passivation layer with liquid crystal. Apply voltage and watch for changes of colour under a microsocope. It is a tricky business at the best of times. > > This is all very odd...It would be interesting to know what might have > caused this. > > Regards > > Ted > > > > > >Article: 127726
On Jan 6, 4:36=A0pm, MikeShepherd...@btinternet.com wrote:
> >Thank you very much. I just wonder whether each LED of the board is
> >physically connected to some pin of FPGA or not?
>
> FInd the circuit diagram ("schematic"). =A0Then look at it. =A0If it
> doesn't make sense, you first need to learn some basic electronics,
> because a lot of the literature you'll meet as you proceed will assume
> that you have that knowledge.
>
> Mike
Thank you, I have found the schematics at Xilinx Web Site. I am really
surprised that I had not noticed this file before. Many thanks!
Article: 127727On Jan 6, 2:54 am, John McCaskill <jhmccask...@gmail.com> wrote: > <snip> > > > 1) Buy a batch of unique addresses (which isn't cheap and involves > > administrative hassle). If you're designing a LAN for an airliner I'm > > going to fly on, I'd like you to use this method. > > Mike, > > While I agree that the MAC ID space is so large that the chance of a > collision for a random address is very low, I do not agree with that > statement. Buying a range of unique addresses is cheap and easy, and > no administrative hassle is involved. > > The IEEE administers MAC IDs, and you can buy a range of them for a > one time fee online. I bought the OUI package online with a credit > card and have no regrets. Take a look at: > > http://standards.ieee.org/regauth/oui/index.shtmlhttp://standards.ieee.org/regauth/oui/pilot-ind.htmlhttp://standards.ieee.org/regauth/oui/forms/ > > You can buy a 4K block of MAC IDs for $500 USD, or a 2^24 block of IDs > for $1650. That is lost in the noise for producing a commercial > product. > > This is a far better deal than I get from the PCI SIG where I have to > pay every year to retain my vendor ID. For the MAC IDs, I pay once and > it is mine for ever. > > While I am a small business owner and complain about every penny > spent, I think that the IEEE gives me a fair deal. Another option is to let the customer set the ID through some configuration option. That way collisions can be avoided post manufacture. And the administrator can't claim that you used an ID "without permission".Article: 127728
The MPMC DDR-Interface is based on the MIG-Memory Controller. Download at http://www.xilinx.com/products/ipcenter/MIG.htm the "User Guide" (ug086.pdf). See page 331/332: Generic Memory Interface Guidelines. Daniel ratemonotonic schrieb: > Hi All , > > I am trying to interface microblaze with a Micron DDR SDRAM > (MT46V16M16FG-75 16Mx16) using MPMC from the IP catalogue. As I am > running on Spartan 3 FPGA I need to connect port lines - DDR_DQS_DIV_O > and DDR_DQS_DIV_I , else I get errors , it also states that these > should be connected in for spartan 3. > > The problem is that there is not much documentation about these port > lines in the MPMC data sheet. Has anyone used this? does any one know > how to connect these lines up? > > thanks in advance > > BR > rateArticle: 127729
Hi All, I have previously send this message to comp.arch.embedded, but probably it was "NTG", as it is more associated with the soft CPU on FPGA problem. Therefore I try once (the last one ;-) ) again in the comp.arch.fpga I have successfully compiled the Plasma soft CPU for my Xilinx Spartan 3E Starter Kit (the version of Plasma core http://www.opencores.org/projects.cgi/web/mips/overview contains the top entity and UCF needed for this board). However I was not able to generate my own software for this CPU. The provided tools ( http://www.opencores.org/projects.cgi/web/mips/gccmips_elf.zip, http://www.opencores.org/projects.cgi/web/mips/tools_bin.zip, http://www.opencores.org/projects.cgi/web/mips/gmake.zip ) are "Windows-only" and unfortunately do not run under wine emulator. I have changed the makefile to make use of the mips-linux-gnu-gcc or mipsel-linux-gnu-gcc packages (available from http://buildd.emdebian.org/debian/ ) It was also necessary to replace some backslashes with slashes. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv # Customize for Linux CC_X86 = gcc -Wall -O -g CP = cp RM = rm -rf #BIN_MIPS = ../../mips/sde/bin VHDL_DIR = ../vhdl #GCC_MIPS = mipsel-linux-gnu-gcc $(CFLAGS) #AS_MIPS = mipsel-linux-gnu-as #LD_MIPS = mipsel-linux-gnu-ld #DUMP_MIPS = mipsel-linux-gnu-objdump GCC_MIPS = mips-linux-gnu-gcc $(CFLAGS) AS_MIPS = mips-linux-gnu-as LD_MIPS = mips-linux-gnu-ld DUMP_MIPS = mips-linux-gnu-objdump # Customize for Windows ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To make sources compiling I had to add the redefiniton of strncat2 to the rtos.h file: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv #define strcpy strcpy2 //don't use intrinsic functions #define strcat strcat2 #define strncat strncat2 // <= added by WZab #define strcmp strcmp2 #define strlen strlen2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Unfortunately, even after this adjustments, there are still problems after "make rtos" I get the following messages: mips-linux-gnu-ld: boot.o: warning: linking PIC files with non-PIC files ../tools/convert_bin.exe test.axf -> code.txt & test.bin Entry=0x10000c50 length=0=0x0 I can try to force mips-linux-gnu-as to generate the PIC file by adding the "-KPIC" option, but then I get the following warning: mips-linux-gnu-as -KPIC -o boot.o ../tools/boot.asm ../tools/boot.asm: Assembler messages: ../tools/boot.asm:35: Warning: No .cprestore pseudo-op used in PIC code ../tools/boot.asm:85: Warning: No .cprestore pseudo-op used in PIC code Anyway the convert_bin complains as before. So I have two questions: 1) How to avoid the problem with PIC code? 2) Is it possible to generate the ROM contents with the standard tool like mips(el)-linux-gnu-objcopy ? Or how to fix the convert to work under linux? -- TIA & Regards, Wojciech M. ZabolotnyArticle: 127730
On 6 Jan, 16:44, Daniel Koethe <dkoe...@nospam-web.de> wrote: > The MPMC DDR-Interface is based on the MIG-Memory Controller. Download > athttp://www.xilinx.com/products/ipcenter/MIG.htmthe "User Guide" > (ug086.pdf). See page 331/332: Generic Memory Interface Guidelines. > > Daniel > > ratemonotonic schrieb: > > > Hi All , > > > I am trying to interface microblaze with a Micron DDR SDRAM > > (MT46V16M16FG-75 16Mx16) using MPMC from the IP catalogue. As I am > > running on Spartan 3 FPGA I need to connect port lines - DDR_DQS_DIV_O > > and DDR_DQS_DIV_I , else I get errors , it also states that these > > should be connected in for spartan 3. > > > The problem is that there is not much documentation about these port > > lines in the MPMC data sheet. Has anyone used this? does any one know > > how to connect these lines up? > > > thanks in advance > > > BR > > rate Hi Daniel , Thanks for the links the doc looks good and I am going through it now. Is the MPMC suitable to interface with asynchronous DDR SDRAMS? i.e. the reference board I am using has Micron MT46V16M16FG-75 16Mx16 part which takes min 75mhz clock. the microblaze on the board is running at 50 Mhz, but the board has 75Mhz clock. In the original design an OPB DDR SBRAM controller was used in which there was seperate control for the DDR clock inputs , but MPMC only seems to take the system clock as an input which is my case is 50 Mhz. How do I produce an 75 Mhz DDR clock from MPMC? Thanks very much , BR RateArticle: 127731
Arlet Ottens <usenet+5@c-scape.nl> wrote: >posedge52@yahoo.com wrote: >> On Jan 5, 10:08 pm, "Pavel.Schu...@gmail.com" >> <Pavel.Schu...@gmail.com> wrote: >>> Hello. >>> Would you please to get me some information about how can i realize >>> UDP transmition with Spartan 3E Starter Kit? Can i use IP supplied >>> with EDK in conjunction with Microblaze. Can I solve the problem >>> without using Microblaze? >> >> You transmitt ethernet packets by waiting for the PHY transmitt clock >> to go low "always @(negedge E_TX_CLK)". Then set E_TX_EN=1 and >> E_TXD[3:0]=first nibble. Then for every event set next nibble. Once >> you have supplied all data. Set E_TX_EN=0 to complete packet. You have >> to wait 24 cycles at 100M before sending a new one. >> The nibbles shall be 555555555555555D - packet data - crc32. Crc32 is >> calculated from packet data only. > >If it is acceptable to hardwire the IP and MAC addresses, then a fairly >straightforward state machine, in combination with a prepared header can >transmit UDP frames. This can be a reasonable solution for a quick hack >on a lab. > >For local networks it is also reasonably safe to omit the UDP checksum. >This can be done by setting it to an all-zeroes value. By doing so, you >can avoid making an extra pass over the data. Actually, you can calculate the CRC on the fly because it is transmitted last. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 127732
Nico Coesel wrote: > Arlet Ottens <usenet+5@c-scape.nl> wrote: > >> If it is acceptable to hardwire the IP and MAC addresses, then a fairly >> straightforward state machine, in combination with a prepared header can >> transmit UDP frames. This can be a reasonable solution for a quick hack >> on a lab. >> >> For local networks it is also reasonably safe to omit the UDP checksum. >> This can be done by setting it to an all-zeroes value. By doing so, you >> can avoid making an extra pass over the data. > > Actually, you can calculate the CRC on the fly because it is > transmitted last. > The Ethernet layer CRC-32 is transmitted last, but the UDP checksum is in the header. Beware that omitting the UDP checksum removes protection against data corruption inside the FPGA, e.g. a bug in the transmit path before the CRC-32 is applied.Article: 127733
ratemonotonic schrieb: > On 6 Jan, 16:44, Daniel Koethe <dkoe...@nospam-web.de> wrote: >> The MPMC DDR-Interface is based on the MIG-Memory Controller. Download >> athttp://www.xilinx.com/products/ipcenter/MIG.htmthe "User Guide" >> (ug086.pdf). See page 331/332: Generic Memory Interface Guidelines. >> >> Daniel >> >> ratemonotonic schrieb: >> >>> Hi All , >>> I am trying to interface microblaze with a Micron DDR SDRAM >>> (MT46V16M16FG-75 16Mx16) using MPMC from the IP catalogue. As I am >>> running on Spartan 3 FPGA I need to connect port lines - DDR_DQS_DIV_O >>> and DDR_DQS_DIV_I , else I get errors , it also states that these >>> should be connected in for spartan 3. >>> The problem is that there is not much documentation about these port >>> lines in the MPMC data sheet. Has anyone used this? does any one know >>> how to connect these lines up? >>> thanks in advance >>> BR >>> rate > > Hi Daniel , > > Thanks for the links the doc looks good and I am going through it now. > Is the MPMC suitable to interface with asynchronous DDR SDRAMS? i.e. > the reference board I am using has Micron MT46V16M16FG-75 16Mx16 part > which takes min 75mhz clock. the microblaze on the board is running at > 50 Mhz, but the board has 75Mhz clock. In the original design an OPB > DDR SBRAM controller was used in which there was seperate control for > the DDR clock inputs , but MPMC only seems to take the system clock as > an input which is my case is 50 Mhz. How do I produce an 75 Mhz DDR > clock from MPMC? The MPMC can not produce a 75Mhz clock from a 50 Mhz source. But the MPMC supports 1:2 System/PIM clock and memory clock. See at page 50 of Datasheet MPMC (DS643) near "<PIM>_Clk". For example you have a 50Mhz source clock, use clk0 (system clock) and clk2x output of a DCM to produce the 100Mhz memory clock. Do not forget to connect clk0 and clkfb to assure zero phase offset. > > Thanks very much , > BR > RateArticle: 127734
John McCaskill wrote: > While I agree that the MAC ID space is so large that the chance of a > collision for a random address is very low, I do not agree with that > statement. Buying a range of unique addresses is cheap and easy, and > no administrative hassle is involved. There is a story that in the beginnings of ethernet using random 48 bit MAC addresses was considered, but rejected because of the (small) probability of two accidentally choosing the same address. As I understand it, in the current system there have been devices produced that accidentally had the same address. As the current system involves humans, such as programming ROMs and installing them in cards, there is a relatively high probability of accidents. Choosing a random 46 bit number with the local administration bit on and the multicast bit off might not be so bad. -- glenArticle: 127735
On Jan 6, 8:40=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Sat, 5 Jan 2008 14:04:04 -0800 (PST), > > FPGA <FPGA.unkn...@gmail.com> wrote: > >function int_to_float (x: signed) return signed > > >I wish to convert the input signed vector to Single precision 32 bit > >floating point number. I do not know what the input string length is > >going to be. Output string length is fixed. > > [...] > > >I am really confused. > > So it would seem. =A0Normally I'm fairly impatient with people > who bring standard homework problems here, but at least you've > been honest and you've made some suggestions. =A0So I'll try to > make some suggestions in return. > > I think you may be a little confused about the way numbers > are represented in binary. =A0Let's start by looking at a > really simple *unsigned* integer - try 11: > > =A0 11 decimal =3D=3D 001011 binary > > Obviously it doesn't matter how many leading zeros you have, > so I've used a total of 6 bits just for the example. > > Each binary digit represents a power of 2: > > =A0 11 decimal =3D =A0 =A00 =A0 =A00 =A0 =A01 =A0 =A00 =A0 =A01 =A0 =A01 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[32] [16] [8] =A0[4] =A0[2] =A0[1] > > I guess you know that. =A0Now let's go to SIGNED > numbers. =A0There are many, many possible ways to > represent signed values in binary, but the method > that's by far the most common for integers, and is > used by "signed" data in the numeric_std package, is > twos complement. =A0In this form, the MOST SIGNIFICANT > bit is negated: > > =A0+11 decimal =3D =A0 =A00 =A0 =A00 =A0 =A01 =A0 =A00 =A0 =A01 =A0 =A01 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [-32] [16] [8] =A0[4] =A0[2] =A0[1] > =A0-30 decimal =3D =A0 =A01 =A0 =A00 =A0 =A00 =A0 =A00 =A0 =A01 =A0 =A00 > > And, in general, any signed number less than 0 will > have its most significant bit set to 1. > > For floating-point representation, however, most people > (you included) use SIGN-AND-MAGNITUDE representation. > In this form, we keep one bit - the sign bit - as a > flag to say whether the number is negative or positive. > Otherwise, we represent the number as a positive number: > > =A0+11 decimal =3D =A0 =A00 =A0 =A0 0 =A0 =A01 =A0 =A00 =A0 =A01 =A0 =A01 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[SIGN] =A0[16] [8] =A0[4] =A0[2] =A0[1] > =A0-11 decimal =3D =A0 =A01 =A0 =A0 0 =A0 =A01 =A0 =A00 =A0 =A01 =A0 =A01 > > OK, so that's integer representation sorted out. =A0Now > let's think about floating-point. > > Have you looked at > =A0http://en.wikipedia.org/wiki/IEEE_754#Single-precision_32_bit > > ??? =A0It seems to me to be splendidly clear. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Thank you Janathan. Your explaination helped a lot. I would like to know the bit width of my result(signed bit stream "interpreted as integer") when i convert single precision number 32 - bit to a signed output(integer range). I understand that in worst case, iwould require 32 bit register to represent all possible integers. Can we instead make this output of variable width(depending on magnitude of input) than keeping it 32 bit. Which would be the best approach? Your advise is appreciatedArticle: 127736
Hi, I can't locate MIG in coregen on Solaris 9.2 and ip update 2? Is it only on Linux and Windows? /michaelArticle: 127737
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >John McCaskill wrote: > >> While I agree that the MAC ID space is so large that the chance of a >> collision for a random address is very low, I do not agree with that >> statement. Buying a range of unique addresses is cheap and easy, and >> no administrative hassle is involved. > >There is a story that in the beginnings of ethernet using random 48 bit >MAC addresses was considered, but rejected because of the (small) >probability of two accidentally choosing the same address. > >As I understand it, in the current system there have been devices >produced that accidentally had the same address. As the current system >involves humans, such as programming ROMs and installing them in cards, >there is a relatively high probability of accidents. > >Choosing a random 46 bit number with the local administration bit >on and the multicast bit off might not be so bad. Yes and no. Like others already pointed out, devices need a serial number anyway. Not just for administration but also to keep track of devices. So having a fixed number (MAC address) assigned to unit xyz generally saves a lot of trouble. Besides, if you are going to generate random MAC addresses you may get intermittant errors because fixed MAC addresses are expected. Those kind of errors are the last you want on a network. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 127738
In article <B_KdnWf0IICN1hzanZ2dnUVZ_t6onZ2d@comcast.com>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > > There is a story that in the beginnings of ethernet using random 48 bit > MAC addresses was considered, but rejected because of the (small) > probability of two accidentally choosing the same address. > > As I understand it, in the current system there have been devices > produced that accidentally had the same address. As the current system > involves humans, such as programming ROMs and installing them in cards, > there is a relatively high probability of accidents. In the early days, address allocations were notified to applicants in the order the bits are transmitted in an ethernet frame on the wire, and a significant number of the early vendors produced loads of kit using completely the wrong OUI as a consequence (with the bits in every octet of the OUI in reverse order). -- Andrew Gabriel [email address is not usable -- followup in the newsgroup]Article: 127739
<snip> > Thank you Janathan. Your explaination helped a lot. > > I would like to know the bit width of my result(signed bit stream > "interpreted as integer") when i convert single precision number 32 - > bit to a signed output(integer range). If you understand how a single precision number is representing in binary you would know how many bits you need as well. > Can we instead make this output of variable width(depending > on magnitude of input) than keeping it 32 bit. No. KJArticle: 127740
Hello, group.
I'm having a heck of a time trying to figure out why my MicroBlaze
implementation is presenting *supposedly* single-precision floating
point values as double-precision values truncated to 32 bits.
Here's what I mean:
float test = 22; // for example
printf("test = 0x%08x\r\n",test); // prints "test = 0x40360000"
printf("test = %d\r\n",test); // prints "test = 1077280768"
printf("test = %f\r\n",test); // prints "test = 22.000000" or
some precision
22 in single-point floating point (hex) is 0x41B00000, and in double-
precision is 0x4036000000000000. So, truncate the double-precision
value and you have what's printed to the screen. I'm completely
baffled. Am I missing something? A gcc flag? How is this even possible
for a single-precision instruction set?
Article: 127741Correct, Linux and Windows only. The workaround is to run the MIG tool on Linux or Windows and transfer the output files over to the Solaris machine for integration. "Michael Laajanen" <michael_laajanen@yahoo.com> wrote in message news:5ud26iF1hgf6pU1@mid.individual.net... > Hi, > > I can't locate MIG in coregen on Solaris 9.2 and ip update 2? > > Is it only on Linux and Windows? > > /michaelArticle: 127742
Hi,
JD Newcomb wrote:
> I'm having a heck of a time trying to figure out why my MicroBlaze
> implementation is presenting *supposedly* single-precision floating
> point values as double-precision values truncated to 32 bits.
>
> Here's what I mean:
>
> float test = 22; // for example
>
> printf("test = 0x%08x\r\n",test); // prints "test = 0x40360000"
> printf("test = %d\r\n",test); // prints "test = 1077280768"
> printf("test = %f\r\n",test); // prints "test = 22.000000" or
> some precision
>
> 22 in single-point floating point (hex) is 0x41B00000, and in double-
> precision is 0x4036000000000000. So, truncate the double-precision
> value and you have what's printed to the screen. I'm completely
> baffled. Am I missing something? A gcc flag? How is this even possible
> for a single-precision instruction set?
If that literally is your test code, GCC might be being a bit too clever
for you and effectively hard coding the literal '22' as the arg to the
printf statements.
Try using
float test = 22.0f;
as the initial assignment for starters. To force single precision
constants you need the 'f' suffix, otherwise you burn tragic number of
cycles doing wasteful double to float conversions.
Also, perhaps specify optimisation level -O0 to gcc, see if that gets
you anywhere.
Regards,
John
Article: 127743Hi, I am designing a viterbi decoder with r=1/2 and k=7 on fpga but don't want to design from scratch. Can one share some reference code for r=1/2 and maybe k=3 etc. which I can use as a base for development. Thanks, SaraArticle: 127744
Thank you, John, for the quick response.
On Jan 6, 10:29 pm, John Williams <jwilli...@itee.uq.edu.au> wrote:
> Hi,
>
>
>
> JD Newcomb wrote:
> > I'm having a heck of a time trying to figure out why my MicroBlaze
> > implementation is presenting *supposedly* single-precision floating
> > point values as double-precision values truncated to 32 bits.
>
> > Here's what I mean:
>
> > float test = 22; // for example
>
> > printf("test = 0x%08x\r\n",test); // prints "test = 0x40360000"
> > printf("test = %d\r\n",test); // prints "test = 1077280768"
> > printf("test = %f\r\n",test); // prints "test = 22.000000" or
> > some precision
>
> > 22 in single-point floating point (hex) is 0x41B00000, and in double-
> > precision is 0x4036000000000000. So, truncate the double-precision
> > value and you have what's printed to the screen. I'm completely
> > baffled. Am I missing something? A gcc flag? How is this even possible
> > for a single-precision instruction set?
>
> If that literally is your test code, GCC might be being a bit too clever
> for you and effectively hard coding the literal '22' as the arg to the
> printf statements.
>
Well, the above wasn't the code that got me investigating the problem
in the first place, but the results are the same.
> Try using
>
> float test = 22.0f;
>
> as the initial assignment for starters. To force single precision
> constants you need the 'f' suffix, otherwise you burn tragic number of
> cycles doing wasteful double to float conversions.
I'm not using constants in my code that pertains to this particular
issue. I have a function that returns an int, and I typecast it to a
float and store it in the float variable:
float foo;
foo = (float) bar(&tmp); // tmp is some 32-bit ASCII-like value
that's converted to an integer value... don't worry about it.
bar() in this case would return 22 as an int, and printing the
variable foo results in the same printed statement as my test code
above.
>
> Also, perhaps specify optimisation level -O0 to gcc, see if that gets
> you anywhere.
>
> Regards,
>
> John
No optimizations also get me the same result. Any other ideas?
Compiler flags I'm not seeing? The other question is: is this even
wrong? I mean, I say it is because calculating the values out by hand
using the IEEE 754 standard shows that the results are wrong. But
using a value like 450.123f in the test code above printed as the 32-
bit truncated double-precision value as 0x40776000 (single-precision
is actually 0x43BB0000). Assuming that the truncation would reduce its
precision, the floating value printed out as 450.122986. [shrug] Maybe
it is right.
Article: 127745
JD Newcomb wrote:
> Hello, group.
>
> I'm having a heck of a time trying to figure out why my MicroBlaze
> implementation is presenting *supposedly* single-precision floating
> point values as double-precision values truncated to 32 bits.
>
> Here's what I mean:
>
> float test = 22; // for example
>
> printf("test = 0x%08x\r\n",test); // prints "test = 0x40360000"
> printf("test = %d\r\n",test); // prints "test = 1077280768"
> printf("test = %f\r\n",test); // prints "test = 22.000000" or
> some precision
>
> 22 in single-point floating point (hex) is 0x41B00000, and in double-
> precision is 0x4036000000000000. So, truncate the double-precision
> value and you have what's printed to the screen. I'm completely
> baffled. Am I missing something? A gcc flag? How is this even possible
> for a single-precision instruction set?
If you use a "%x" or "%d" argument, printf() will only print a 32-bit
integer, no matter what you pass as the argument. Any additional bits in
the argument will just be ignored.
If you want to find out how many bytes are used in the implementation, try:
printf( "float: %d, double %d\n", sizeof(float), sizeof(double) );
If sizeof() returns a value greater than 4 bytes, you may want to try
printing it as a 64 bit integer argument, using:
printf( "test %llx\n", test );
Note that this isn't guaranteed to produce any meaningful results.
Article: 127746
JD Newcomb wrote:
> float test = 22; // for example
> printf("test = 0x%08x\r\n",test); // prints "test = 0x40360000"
> printf("test = %d\r\n",test); // prints "test = 1077280768"
> printf("test = %f\r\n",test); // prints "test = 22.000000" or
> some precision
> 22 in single-point floating point (hex) is 0x41B00000, and in double-
> precision is 0x4036000000000000. So, truncate the double-precision
> value and you have what's printed to the screen. I'm completely
> baffled. Am I missing something? A gcc flag? How is this even possible
> for a single-precision instruction set?
That is C.
C always converts (float) to (double) before passing it to a
varargs function. %f expects a double, not a float, as it will
always be converted before the call.
try:
printf("test = 0x%08x\r\n",*(int*)&test);
(assumes sizeof(float)==sizeof(int), but you were already
assuming that.)
-- glen
Article: 127747Hi Jim, Thanks a lot for the link. I really found this tool very useful. Kevin, thanks for the reply. I know I can do that but I was looking for a simpler alternative. -- GoliArticle: 127748
iqbalmuh@hotmail.co.uk schrieb: > Hi, > > Can anyone tell me what this bit of code is doing ? > > -- declarations > ------------------------------------------------------------------------------------------- > signal phase : std_logic_vector(6 downto 0); > > type INTEGER_ARRAY is array ( natural range <> ) of integer; > > constant NUMERATOR : INTEGER_ARRAY(7 downto 0) := (7,30,7,7, 30, 30, > 30,30); > > variable phase_next : std_logic_vector(6 downto 0); > -------------------------------------------------------------------------------------------- > > -- **** problem code ********** > > phase_next := phase + NUMERATOR(conv_integer(std)); > > Obviously the conv_integer(std) part of the code is being used to > access the array NUMERATOR but I don't understand exactly how since no > number value is being specified to key into the array > ie. what is the value of 'std' that is being converted to an integer > by the function 'conv_integer' ? > > Thanks Hi, just two guesses: 1.) there's a port named std in the entity. 2.) your code snippet is just wrong in that line (copy & paste error or uncompleted template) Have a nice synthesis EilertArticle: 127749
Hello, I'd suggest that you try compiling your own mips gcc cross-compiler on your linux machine, using as target *mipsel-elf* (I am using it for Plasma). Below is a makefile that should automate most of the job (beware of wrapped lines). Hope it can help. Steven GCC_VER=gcc-4.0.2 BINUTILS_VER=binutils-2.16.1 GDB_VER=gdb-6.6 INSIGHT_VER=insight-6.6 TARGET = mipsel INSTALL_DIR= /opt/mipsic/ all: @echo "## GNU SDK builder (binutil-gcc-gdb) for target machine $(TARGET) " @echo " 1) Make sure that Makefile variable INSTALL_DIR shall point to an *existing* installation directory" @echo " 2) Create a new environment variable MIPSIC and set its value to $(INSTALL_DIR)" @echo " 3) Check that your PATH environmenet variable points to $(INSTALL_DIR)/bin " @echo " 4) Run make build_sdk" insight : $(INSTALL_DIR)/bin/$(TARGET)-elf-insight binutils : $(INSTALL_DIR)/bin/$(TARGET)-elf-ar gdb : $(INSTALL_DIR)/bin/$(TARGET)-elf-gdb gcc : $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc utils : $(INSTALL_DIR)/bin/bin2mif \ $(INSTALL_DIR)/bin/bin2hex # $(INSTALL_DIR)/bin/hex2mif \ # $(INSTALL_DIR)/bin/elf2bin \ build_sdk : \ $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc \ $(INSTALL_DIR)/bin/$(TARGET)-elf-gdb \ $(INSTALL_DIR)/bin/$(TARGET)-elf-insight \ $(INSTALL_DIR) : mkdir -p $(INSTALL_DIR) export PATH=$PATH:$(INSTALL_DIR)/bin # # Binutils # build : -mkdir build $(BINUTILS_VER).tar.bz2 : @echo Downloading $(BINUTILS_VER) @wget ttp://ftp.gnu.org/pub/gnu/binutils/$(BINUTILS_VER).tar.bz2 build/$(BINUTILS_VER)/ : $(BINUTILS_VER).tar.bz2 build @echo Uncompressing $(BINUTILS_VER) @tar xvfj $(BINUTILS_VER).tar.bz2 > /dev/null mv $(BINUTILS_VER) build/$(BINUTILS_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-objdump : build/$(BINUTILS_VER) $(INSTALL_DIR) cd build/$(BINUTILS_VER); \ ./configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf ;\ make ;\ make install ;\ cd ../ # # gcc # $(GCC_VER).tar.bz2 : @echo Downloading $(GCC_VER) @wget http://ftp.gnu.org/pub/gnu/gcc/$(GCC_VER)/$(GCC_VER).tar.bz2 build/$(GCC_VER)/ : $(GCC_VER).tar.bz2 @echo Uncompressing $(GCC_VER) @tar xvfj $(GCC_VER).tar.bz2 > /dev/null mv $(GCC_VER) build/$(GCC_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc : build/$(GCC_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-objdump cd build/ ; ./$(GCC_VER)/configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf --enable-languages=c ;\ make ;\ make install # # gdb # $(GDB_VER).tar.bz2 : @echo Downloading $(GDB_VER) wget http://ftp.gnu.org/pub/gnu/gdb/$(GDB_VER).tar.bz2 build/$(GDB_VER)/ : $(GDB_VER).tar.bz2 build @echo Uncompressing gdb tar xvfj $(GDB_VER).tar.bz2 > /dev/null mv $(GDB_VER) build/$(GDB_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-gdb : build/$(GDB_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc cd build/$(GDB_VER); \ sh ./configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf ;\ make ;\ make install ;\ cd ../ # # insight-gdb # $(INSIGHT_VER).tar.bz2 : @echo Downloading $(INSIGHT_VER) wget http://mirrors.kernel.org/sources.redhat.com/insight/releases/$(INSIGHT_VER).tar.bz2 build/$(INSIGHT_VER) : $(INSIGHT_VER).tar.bz2 build @echo Uncompressing insight-gdb @tar xvfj $(INSIGHT_VER).tar.bz2 > /dev/null mv $(INSIGHT_VER) build/$(INSIGHT_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-insight : build/$(INSIGHT_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc cd build/$(INSIGHT_VER)/ ;\ ./configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf ;\ make ;\ make install ;\ cd ../ # clean real_clean : cd build ; \rm -r * # # scripts # $(INSTALL_DIR)/bin/mips-assembler: cp scripts/* $(INSTALL_DIR)/bin/ # archive zip : cd .. ; zip -r mips-devkit.zip mips-devkit Wojciech Zabolotny a écrit : > Hi All, > > I have previously send this message to comp.arch.embedded, but probably it > was "NTG", as it is more associated with the soft CPU on FPGA problem. > Therefore I try once (the last one ;-) ) again in the comp.arch.fpga > > > I have successfully compiled the Plasma soft CPU for my Xilinx Spartan 3E > Starter Kit (the version of Plasma core > http://www.opencores.org/projects.cgi/web/mips/overview > contains the top entity and UCF needed for this board). > > However I was not able to generate my own software for this CPU. > The provided tools ( > http://www.opencores.org/projects.cgi/web/mips/gccmips_elf.zip, > http://www.opencores.org/projects.cgi/web/mips/tools_bin.zip, > http://www.opencores.org/projects.cgi/web/mips/gmake.zip > ) > are "Windows-only" and unfortunately do not run under wine emulator. > > I have changed the makefile to make use of the mips-linux-gnu-gcc > or mipsel-linux-gnu-gcc packages (available from > http://buildd.emdebian.org/debian/ ) > > It was also necessary to replace some backslashes with slashes. > > vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > # Customize for Linux > CC_X86 = gcc -Wall -O -g > CP = cp > RM = rm -rf > #BIN_MIPS = ../../mips/sde/bin > VHDL_DIR = ../vhdl > #GCC_MIPS = mipsel-linux-gnu-gcc $(CFLAGS) > #AS_MIPS = mipsel-linux-gnu-as > #LD_MIPS = mipsel-linux-gnu-ld > #DUMP_MIPS = mipsel-linux-gnu-objdump > GCC_MIPS = mips-linux-gnu-gcc $(CFLAGS) > AS_MIPS = mips-linux-gnu-as > LD_MIPS = mips-linux-gnu-ld > DUMP_MIPS = mips-linux-gnu-objdump > > # Customize for Windows > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > To make sources compiling I had to add the redefiniton > of strncat2 to the rtos.h file: > > vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > #define strcpy strcpy2 //don't use intrinsic functions > #define strcat strcat2 > #define strncat strncat2 // <= added by WZab > #define strcmp strcmp2 > #define strlen strlen2 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Unfortunately, even after this adjustments, there are still problems > after "make rtos" I get the following messages: > > mips-linux-gnu-ld: boot.o: warning: linking PIC files with non-PIC files > > ../tools/convert_bin.exe > test.axf -> code.txt & test.bin > Entry=0x10000c50 length=0=0x0 > > I can try to force mips-linux-gnu-as to generate the PIC file by > adding the "-KPIC" option, but then I get the following warning: > > mips-linux-gnu-as -KPIC -o boot.o ../tools/boot.asm > ../tools/boot.asm: Assembler messages: > ../tools/boot.asm:35: Warning: No .cprestore pseudo-op used in PIC code > ../tools/boot.asm:85: Warning: No .cprestore pseudo-op used in PIC code > > Anyway the convert_bin complains as before. > > So I have two questions: > 1) How to avoid the problem with PIC code? > 2) Is it possible to generate the ROM contents with the standard tool like > mips(el)-linux-gnu-objcopy ? > Or how to fix the convert to work under linux?
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