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
CBFalconer wrote:
> You didn't leave much of a quote.
Sorry. The OP said:
> So why do all synthesis tools propose "gray code" as one of the
> encodings of state machines ?
> Assuming this has to do with
> Gray codes, there is no reason to assume the source can be clocked,
> in fact this is relatively rare. In general source values change
> when they are in the appropriate mood. Now deal with the result.
My points for the OP were that
1.Most state machines used
in practical controllers are synchronous
and
2. Their state graphs are not a simple
loop like a counter. This makes it difficult
to maintain a Gray encoding for all transitions in any case.
-- Mike
From Iwo.Mergler@soton.sc.philips.com Wed Sep 12 07:36:41 2007
Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!novia!newsfeed.yul.equant.net!lon04-news-philips!53ab2750!not-for-mail
Message-Id: <p4alr4-u6h.ln1@c2968.soton.sc.philips.com>
From: Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>
Subject: Re: [Nios II] How fast the cpu in Nios II can reach in the Cycone ?
Newsgroups: comp.arch.fpga
References: <1189583937.448219.313990@r29g2000hsg.googlegroups.com>
Lines: 52
Organization: Not organised
User-Agent: KNode/0.9.2
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8Bit
Date: Wed, 12 Sep 2007 15:36:41 +0100
NNTP-Posting-Host: 161.85.127.140
X-Complaints-To: newsmaster@rain.fr
X-Trace: lon04-news-philips 1189608493 161.85.127.140 (Wed, 12 Sep 2007 14:48:13 GMT)
NNTP-Posting-Date: Wed, 12 Sep 2007 14:48:13 GMT
Bytes: 1981
X-Original-Bytes: 1938
Xref: prodigy.net comp.arch.fpga:136049
X-Received-Date: Wed, 12 Sep 2007 10:47:37 EDT (newsdbm02.news.prodigy.net)
lexluthor wrote:
>
>
> 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?
Short answer: no.
Medium answer:
Your code will look roughly like this in pseudo-assembler:
load R1,PIO_0_BASE # target address
load R2,0 # data initialization
loop:
store R2,[R1]
incr R2
jump loop
The fast version of NIOS II takes roughly two clock
cycles per instruction - a 100MHz clock should give
you around 50MIPS best case.
In your loop you will need three instructions per iteration.
The code will fit into the single-cycle cache, freeing
up the bus.
The PIO implementation uses a single cycle write, so assuming
you placed it on the same bus as the processor, this won't
be a bottleneck.
So your best-case rate of change on the PIO port
is a little under 17MHz.
Kind regards,
Iwo
Article: 124126David 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, CharlesArticle: 124127
Hi Goran,
I am using type cast to single in matlab. Once you round the first
variable to single in matlab, it should round everything after that to
single already. Cos all resulting variables after that are already in
single precision. right?
by the way, you say " In order to get exactly the same every result
operation in Matlab has to be
done in single-precision."
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?
Is the FPU inaccurate or am i seeing things...
Chris
On Sep 12, 4:54 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote:
> Hi,
>
> What rounding mode are you using for Matlab?
> MicroBlaze only uses round-to-nearest rounding mode.
>
> In order to get exactly the same every result operation in Matlab has to =
be
> done in single-precision.
>
> G=F6ran
>
> "chriskoh" <chrisde...@yahoo.com> wrote in message
>
> news:1189590703.769514.104310@57g2000hsv.googlegroups.com...
>
>
>
> > 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- Hide quoted text -
>
> - Show quoted text -
Article: 124128On 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.Article: 124129
Hi, May 2 cents : It seems to me that Desktop PC FPU use larger mantissa internally than what is strictly required by the IEEE SP standard, especially for some operations (such as /,sqrt). That *might* explain your results. Also, did you check that the matrix inversion algorithm you used is robust enough in terms of numerical stability ? Hope it can help. Steven chriskoh a écrit : > Hi Goran, > I am using type cast to single in matlab. Once you round the first > variable to single in matlab, it should round everything after that to > single already. Cos all resulting variables after that are already in > single precision. right? > > by the way, you say " In order to get exactly the same every result > operation in Matlab has to be > done in single-precision." > > 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? > > Is the FPU inaccurate or am i seeing things... > > > Chris > > > On Sep 12, 4:54 am, "Göran Bilski" <goran.bil...@xilinx.com> wrote: > >>Hi, >> >>What rounding mode are you using for Matlab? >>MicroBlaze only uses round-to-nearest rounding mode. >> >>In order to get exactly the same every result operation in Matlab has to be >>done in single-precision. >> >>Göran >> >>"chriskoh" <chrisde...@yahoo.com> wrote in message >> >>news:1189590703.769514.104310@57g2000hsv.googlegroups.com... >> >> >> >> >>>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- Hide quoted text - >> >>- Show quoted text - > > >Article: 124130
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, AntonioArticle: 124131
Hi Steven,
so matlab results are more accurate?
the matrix inversion algorithm method is rather robust actually in
terms of numerical stability. What I noticed however is that the
matrix formed already by my C code running on microblaze before the
inversion has already some numerical differences with matlab's
version. simple C code vs matlab single precision code.
but different results obtained. All discovered by stepping through the
C code running on microblaze.
the matrix was formed simply by a dot product.
Chris
On Sep 12, 10:15 am, Steven Derrien <sderrienREM...@irisa.fr> wrote:
> Hi,
>
> May 2 cents : It seems to me that Desktop PC FPU use larger mantissa
> internally than what is strictly required by the IEEE SP standard,
> especially for some operations (such as /,sqrt). That *might* explain
> your results.
>
> Also, did you check that the matrix inversion algorithm you used is
> robust enough in terms of numerical stability ?
>
> Hope it can help.
>
> Steven
>
> chriskoh a =E9crit :
>
>
>
> > Hi Goran,
> > I am using type cast to single in matlab. Once you round the first
> > variable to single in matlab, it should round everything after that to
> > single already. Cos all resulting variables after that are already in
> > single precision. right?
>
> > by the way, you say " In order to get exactly the same every result
> > operation in Matlab has to be
> > done in single-precision."
>
> > 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?
>
> > Is the FPU inaccurate or am i seeing things...
>
> > Chris
>
> > On Sep 12, 4:54 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote:
>
> >>Hi,
>
> >>What rounding mode are you using for Matlab?
> >>MicroBlaze only uses round-to-nearest rounding mode.
>
> >>In order to get exactly the same every result operation in Matlab has t=
o be
> >>done in single-precision.
>
> >>G=F6ran
>
> >>"chriskoh" <chrisde...@yahoo.com> wrote in message
>
> >>news:1189590703.769514.104310@57g2000hsv.googlegroups.com...
>
> >>>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- Hide quoted text -
>
> >>- Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Article: 124132Hi, I just bought "Student's VHDL Guide" by Ashenden. What is the difference between the following two books by the same author: The Designer's Guide to VHDL (Systems on Silicon) by Peter J. Ashenden (Paperback - May 2002) Buy new: $75.95 $56.19 40 Used & new from $49.18 The System Designer's Guide to VHDL-AMS (Systems on Silicon) by Peter J. Ashenden, Gregory D. Peterson, and Darrell A. Teegarden (Paperback - Sep 4, 2002) Buy new: $81.95 $60.57 23 Used & new from $55.00 WengArticle: 124133
On Wed, 12 Sep 2007 09:13:48 -0700, chriskoh <chrisdekoh@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. PaulArticle: 124134
Yes, Symon, that's shorter.Article: 124135
Charles, you are right. The identity comparison of two Gray counters avoids accidental glitches, but does not avoid the inherent asynchronous nature of the event. The design still has to resolve (better: live with) the matastability issue. Luckily, modern flip-flops resolve metastability pretty fast, at least statistically. XAPP094 is a Xilinx app note that quantifies the results for Virtex2Pro FPGAs. Peter Alfke On Sep 12, 9:13 am, "Charles, NG" <site_blackh...@trellisys.ie> 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, > CharlesArticle: 124136
Could we expect the same step from Lattice? Or Xilinx will come with this possibility sooner? http://www.altera.com/products/ip/processors/32_16bit/m-arm-cortex-m1.html http://www.fpgajournal.com/articles_2007/20070911_arm.htm VitaArticle: 124137
On Sep 12, 12:53 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > Yes, Symon, that's shorter. Have you thought about what happens to bus2ip_data before the magic address is hit? What about after it has been hit? What else (if anything) is driving bus2ip_data? If nothing, bus2ip_data will be (others => 'U') before, and X"FF00FF00" after, forevermore. If something else is driving data, then a (others => 'X') will almost certainly result. AndyArticle: 124138
On Sep 12, 12:47 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi, > I just bought "Student's VHDL Guide" by Ashenden. > > What is the difference between the following two books by the same > author: > > The Designer's Guide to VHDL (Systems on Silicon) by Peter J. Ashenden > (Paperback - May 2002) > Buy new: $75.95 $56.19 40 Used & new from $49.18 > > The System Designer's Guide to VHDL-AMS (Systems on Silicon) by Peter > J. Ashenden, Gregory D. Peterson, and Darrell A. Teegarden (Paperback > - Sep 4, 2002) > Buy new: $81.95 $60.57 23 Used & new from $55.00 > > Weng The latter is for vhdl-ams (analog mixed signal?), and probably has more to do with the analog aspects of it. AndyArticle: 124139
> Have you thought about what happens to bus2ip_data before the magic > address is hit? What about after it has been hit? No, I had not thought of it. I was just correcting the obvious lack of a clk if-then and hopefully explaining why he got zeroes. Perhaps, there is another driver. > What else (if anything) is driving bus2ip_data? If nothing, > bus2ip_data will be (others => 'U') before, and X"FF00FF00" after, > forevermore. > > If something else is driving data, then a (others => 'X') will almost > certainly result. > > Andy >Article: 124140
Thanks Martin, 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 or how to use GNU, although for you keyboard guys, I hear it's great. Brad Smallridge "Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:ud4womgpr.fsf@trw.com... > "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: 124141
I'm trying to get a Spartan3E FPGA to communicate with a PC. I'm
using lwIP and Microblaze and have managed to get the FPGA to receive
packets fine, but despite it appearing to bind and connect the socket
for transmitting data, I don't receive any data. The code is below.
Your help would be greatly appriciated.
Thanks,
SC
/***************************** Include Files
*********************************/
/* Xilinx Includes */
#include "xstatus.h" // Required for status checks on peripheral
functions
#include "xgpio.h" // Required for GPIO peripherals
#include "xmk.h"
/* C Library Includes */
#include "string.h" // Required for memset and strtok
/* lwIP Includes */
#include "netif/xemacif.h"
#include "lwip/udp.h"
#include "lwip/memp.h"
#include "netif/etharp.h"
#include "lwip/sys.h"
#include "lwip/sockets.h"
// OPB Timer/Counter Device Driver
#include "xtmrctr.h"
#include "Ethernet_10.h"
/************************** Variable Definitions
******************************/
extern XEmacIf_Config XEmacIf_ConfigTable[];
int numConnections;
int incoming_buffer_len;
int incoming_sock, outgoing_sock;
struct sockaddr_in incoming_udp, outgoing_udp;
XTmrCtr udp_transmitter_timer;
/
*****************************************************************************
*
* This is the UDP Transmitter Application Thread
*
* @param baseaddr_p is the Base Address of OPB_Timer_0
*
* @return None
*
* @note None
*
******************************************************************************/
void udp_transmitter_int_handler (void* arg) {
char writeBuffer[6];
xil_printf("Sending Data\r\n");
writeBuffer[0] = 'a';
writeBuffer[1] = 'b';
writeBuffer[2] = 'c';
writeBuffer[3] = 'd';
writeBuffer[4] = 'e';
writeBuffer[5] = 'f';
// write(outgoing_sock, "writeBuffer", 11); //hanging here
// udp_send(outgoing_sock, "a"); //hanging here
// Resets the UDP Transmitter Timer to a start mode
XTmrCtr_Reset(&udp_transmitter_timer, 0);
}
/
*****************************************************************************
*
* This is the Network Listener Application Thread
*
* @param sd - Socket ID
*
* @return None
*
* @note None
*
******************************************************************************/
void* processConnection(struct sockaddr_in input, int connections)
{
// char receiveBuffer[6];//RECV_BUFFER_LENGTH];
// int sd = *((int*) arg);
// int bytesReceived;
// Read the request data
xil_printf("Data : %s \r\n", &incoming_udp);
// xil_printf("Data Recieved: ");
// xil_printf(&input);
// xil_printf("\n\r");
// xil_printf("Connections: ");
// close(&input);
numConnections--;
}
/
*****************************************************************************
*
* This is the UDP Application Thread, it generates and listens to udp
traffic
*
* @param sd - Socket ID
*
* @return None
*
* @note None
*
******************************************************************************/
void* udpAppThread(void* arg)
{
int i;
int leds_disp;
int switches_value;
int size;
int status;
unsigned char mac_address[6];
unsigned char ip_address[4];
unsigned char gateway_addr[4];
unsigned char subnet[4];
struct ip_addr ipaddr, netmask, gateway;
struct netif *server_netif;
XEmacIf_Config *xemacif_ptr = &XEmacIf_ConfigTable[0];
XStatus udp_transmitter_initialized;
Xuint32 udp_transmitter_status;
XStatus register_setup_status;
// MAC Address = 00-00-00-00-22-31
memset(mac_address, 0, 6);
mac_address[0] = 0x00;
mac_address[1] = 0x00;
mac_address[2] = 0x00;
mac_address[3] = 0x00;
mac_address[4] = 0x22;
mac_address[5] = 0x31;
xemacif_setmac(0, (u8_t *)mac_address);
// Netmask = 255.255.255.0
netmask.addr = htonl(0xffffff00);
// Gateway = 10.1.2.1
gateway.addr = htonl(0x0a010201);
// IP Address = 10.1.2.101
ipaddr.addr = htonl(0x0a010265);
// Set up the lwIP network interface
// Allocate and configure the server's netif
server_netif = mem_malloc(sizeof(struct netif));
if(server_netif == NULL)
{
xil_printf("ERROR: netif_add(): Out of memory for default netif
\n\r");
return;
}
server_netif = netif_add(server_netif,
&ipaddr,
&netmask,
&gateway,
&XEmacIf_ConfigTable[0],
xemacif_init,
ip_input);
netif_set_default(server_netif);
// Register the XEMAC interrupt handler with the controller and
enable
// interrupts within XMK
register_int_handler(XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR,
(XInterruptHandler)XEmac_IntrHandlerFifo,
xemacif_ptr->instance_ptr);
enable_interrupt(XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR);
// Create and bind the socket. Because the MicroBlaze and PowerPC
processors
// are big-endian architectures, the calls to htons(), htonl(),
etc. aren't
// necessary, but are included for completeness and portability
incoming_sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
incoming_udp.sin_family = AF_INET;
incoming_udp.sin_port = htons(VMS_PORT);
incoming_udp.sin_addr.s_addr = INADDR_ANY;
bind(incoming_sock, (struct sockaddr*)&incoming_udp, sizeof(struct
sockaddr));
outgoing_sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
outgoing_udp.sin_family = AF_INET;
outgoing_udp.sin_port = htons(90);
outgoing_udp.sin_addr.s_addr = htonl(0x0a010264);
status = bind(outgoing_sock, (struct sockaddr*)&outgoing_udp,
sizeof(struct sockaddr));
xil_printf("%d bind\r\n",status);
status = connect(outgoing_sock, (struct sockaddr*)&outgoing_udp,
sizeof(struct sockaddr));
xil_printf("%d connect\r\n",status);
xil_printf("Server initialization complete.\r\n");
// Begin listening on the socket. For all new connections, spawn a
new
// thread, processConnection(), to deal with them
listen(incoming_sock, 20);
numConnections = 0;
// Initializes opb_timer_0 as udp_transmitter_timer
udp_transmitter_initialized =
XTmrCtr_Initialize(&udp_transmitter_timer,
XPAR_OPB_TIMER_0_DEVICE_ID);
if (udp_transmitter_initialized == XST_SUCCESS)
{
xil_printf("-- UDP Transmitter was initialized --\r\n");
} else {
if (udp_transmitter_initialized == XST_DEVICE_IS_STARTED)
{
xil_printf("-- UDP Transmitter was already initialized --\r
\n");
} else {
xil_printf("-- UDP Transmitter was not found --\r\n");
}
}
//Sets options for udp transmitter timer
XTmrCtr_SetOptions(&udp_transmitter_timer, 0, // set the 0 timer
in opb_timer_0
XTC_DOWN_COUNT_OPTION | // See page 3 on OPB Timer/Counter
v1.00b in regards to count down
XTC_INT_MODE_OPTION | // Enables the timer counter
interrupt output.
XTC_AUTO_RELOAD_OPTION); // And reload the "reset" value and
begin counting again
// set timer on 1 second interval
XTmrCtr_SetResetValue(&udp_transmitter_timer, 0, 50000000);
// Sets the UDP Transmitter Timer to a stop mode
XTmrCtr_Stop(&udp_transmitter_timer, 0);
// timer_int_handler process will execute on opb_timer_0 interrupt
register_setup_status =
register_int_handler(XPAR_OPB_INTC_0_OPB_TIMER_0_INTERRUPT_INTR,
udp_transmitter_int_handler, NULL);
enable_interrupt(XPAR_OPB_INTC_0_OPB_TIMER_0_INTERRUPT_INTR);
if (register_setup_status == XST_SUCCESS)
{
xil_printf("-- Interrupt Successfully Created --\r\n");
} else {
xil_printf("Interrupt Error : ");
putnum(register_setup_status);
xil_printf("\r\n");
}
// Sets the UDP Transmitter Timer to a start mode
XTmrCtr_Start(&udp_transmitter_timer, 0);
while(1)
{
// Will wait at the line below till code is recieved.
incoming_buffer_len = read(incoming_sock, (struct sockaddr
*)&incoming_udp, sizeof(struct sockaddr));
// Increases numConnections everyime new connection is read.
// numConnections will decrease after connection is dropped
numConnections++;
xil_printf("%d bytes of data \r\n", incoming_buffer_len);
// Spawn a new thread to handle the data for the new
connection
sys_thread_new((void *)&processConnection, &incoming_sock,
numConnections);
}
}
/
*****************************************************************************
*
* This is the Top Level Application Thread. It will start all other
* Application Threads.
*
* @param None
*
* @return None
*
* @note None
*
******************************************************************************/
void serverThread (void* arg) {
// Initialize the lwIP library
xil_printf("Initializing the lwIP library...\r\n");
lwip_init();
//mem_init();
//memp_init();
//pbuf_init();
//netif_init();
//udp_init();
// Sleep to allow lwIP initialization status messages to display
// without interruption
sleep(100);
xil_printf("lwIP initialization done\n\r");
// Spawn the UDP communication application thread
sys_thread_new((void *)&udpAppThread, 0, 0);
xil_printf("udpAppThread Started\n\r");
}
int main (void) {
// Launch XMK
xilkernel_main();
return 0;
}
Article: 124142"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:13egfkk93bre309@corp.supernews.com... > > Don't know what c.a.f. stands for comp.arch.fpga :) /MikhailArticle: 124143
Some of the sources in the MB assembler were not really written in a 64-bit
safe fashion. The particular error that you are seeing is due to mismatched
type expansion for integer constants in the code. There are similair type
expansion bugs in the compiler as well due to missing prototypes for some
functions.
None of these issues affect 32-bit compilation. However, we are fixing these
bugs in the EDK 9.2i release so that the tools do build cleanly and produce
correct output on 64-bit machines.
Here are a couple of patches to get you going in the meanwhile. The patches
will not apply cleanly against your version of sources, so I am afraid you
will have to apply them manually. The changes are minor though, so it
shouldn't be too hard.
Vasanth
"taco" <tralalal@joepie.nl> wrote in message
news:fc83fr$qnm$1@usenet.uva.nl...
> 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/
begin 666 gcc_microblaze_protos.patch
M9&EF9B M=7).<"!G8V,M;W)I9R]G8V,O8V]N9FEG+VUI8W)O8FQA>F4O;6EC
M<F]B;&%Z92YC(&=C8R]G8V,O8V]N9FEG+VUI8W)O8FQA>F4O;6EC<F]B;&%Z
M92YC"BTM+2!G8V,M;W)I9R]G8V,O8V]N9FEG+VUI8W)O8FQA>F4O;6EC<F]B
M;&%Z92YC"3(P,#<M,#8M,C @,3,Z-#,Z,S0N,# P,# P,# P("TP-S P"BLK
M*R!G8V,O9V-C+V-O;F9I9R]M:6-R;V)L87IE+VUI8W)O8FQA>F4N8PDR,# W
M+3 V+3(P(#$T.C(X.C,S+C P,# P,# P," M,#<P, I 0" M,C S+#@@*S(P
M,RPV($! (&EN="!S:6UP;&5?;65M;W)Y7V]P97)A;F0@"0D)4$%204U3("@H
M<G0*('9O:60@=')A8V4@"0D)"0E005)!35,@*"AC;VYS="!C:&%R("HL(&-O
M;G-T(&-H87(@*BP@8V]N<W0@8VAA<B J*2D["B!V;VED(&=E;E]C;VYD:71I
M;VYA;%]B<F%N8V@@"0D)4$%204U3("@H<G1X("HL(&5N=6T@<G1X7V-O9&4I
M*3L*('9O:60@:6YI=%]C=6UU;&%T:79E7V%R9W,@"0D)4$%204U3("@H0U5-
M54Q!5$E615]!4D=3("HL=')E92P@<G1X*2D["BUV;VED(&9U;F-T:6]N7V%R
M9U]A9'9A;F-E( D)"5!!4D%-4R H*$-5355,051)5D5?05)'4R J+"!E;G5M
M(&UA8VAI;F5?;6]D92P@=')E92P@:6YT*2D["BUS=')U8W0@<G1X7V1E9B J
M9G5N8W1I;VY?87)G( D)"5!!4D%-4R H*$-5355,051)5D5?05)'4R J+"!E
M;G5M(&UA8VAI;F5?;6]D92P@=')E92P@:6YT*2D["B!I;G0@9G5N8W1I;VY?
M87)G7W!A<G1I86Q?;G)E9W,@"0D)4$%204U3("@H0U5-54Q!5$E615]!4D=3
M("HL(&5N=6T@;6%C:&EN95]M;V1E+"!T<F5E+"!I;G0I*3L*($A/4U1?5TE$
M15])3E0@;6EC<F]B;&%Z95]D96)U9V=E<E]O9F9S970@"5!!4D%-4R H*')T
M>"P@2$]35%]7241%7TE.5"DI.PH@=F]I9"!M:6-R;V)L87IE7V]U='!U=%]L
M:6YE;F\@"0D)4$%204U3("@H1DE,12 J+"!I;G0I*3L*0$ @+3(W,C$L-R K
M,C<Q.2PW($! (&9U;F-T:6]N7V%R9U]A9'9A;F-E("@*("\J(%)E='5R;B!A
M;B!25$P@97AP<F5S<VEO;B!C;VYT86EN:6YG('1H92!R96=I<W1E<B!F;W(@
M=&AE(&=I=F5N(&UO9&4L"B @("!O<B P(&EF('1H92!A<F=U;65N="!I<R!T
M;R!B92!P87-S960@;VX@=&AE('-T86-K+B @*B\*( HM<W1R=6-T(')T>%]D
M968@*@HK<G1X"B!F=6YC=&EO;E]A<F<@* H@("!#54U53$%4259%7T%21U,@
M*F-U;2P)"2\J(&-U<G)E;G0@87)G(&EN9F]R;6%T:6]N("HO"B @(&5N=6T@
M;6%C:&EN95]M;V1E(&UO9&4L"2\J(&-U<G)E;G0@87)G(&UO9&4@*B\*9&EF
M9B M=7).<"!G8V,M;W)I9R]G8V,O8V]N9FEG+VUI8W)O8FQA>F4O;6EC<F]B
M;&%Z92UP<F]T;W,N:"!G8V,O9V-C+V-O;F9I9R]M:6-R;V)L87IE+VUI8W)O
M8FQA>F4M<')O=&]S+F@*+2TM(&=C8RUO<FEG+V=C8R]C;VYF:6<O;6EC<F]B
M;&%Z92]M:6-R;V)L87IE+7!R;W1O<RYH"3(P,#<M,#8M,C @,3,Z-#,Z,S0N
M,# P,# P,# P("TP-S P"BLK*R!G8V,O9V-C+V-O;F9I9R]M:6-R;V)L87IE
M+VUI8W)O8FQA>F4M<')O=&]S+F@),C P-RTP-BTR," Q-#HR.#HT-2XP,# P
M,# P,# @+3 W,# *0$ @+3,X+#0@*S,X+#$Q($! (&5X=&5R;B!V;VED('-H
M:69T7V1O=6)L95]L969T7VEM;2 @("!005(*(&5X=&5R;B!V;VED(&]V97)R
M:61E7V]P=&EO;G,@*'9O:60I.PH@97AT97)N('9O:60@;6%C:&EN95]D97!E
M;F1E;G1?<F5O<F<@4$%204U3("@H=F]I9"DI.PH@(V5N9&EF(" O*B!25%A?
M0T]$12 J+PHK"BLC:69D968@5%)%15]#3T1%"BME>'1E<FX@=F]I9"!F=6YC
M=&EO;E]A<F=?861V86YC92 H0U5-54Q!5$E615]!4D=3("HL(&5N=6T@;6%C
M:&EN95]M;V1E+ HK"0D)"2 @=')E92P@:6YT*3L**V5X=&5R;B!R='@@9G5N
M8W1I;VY?87)G("A#54U53$%4259%7T%21U,@*BP@96YU;2!M86-H:6YE7VUO
M9&4L('1R964L(&EN="D["BLC96YD:68@+RH@5%)%15]#3T1%("HO"BL*("-E
M;F1I9B @+RH@7U]-24-23T),05I%7U!23U1/4U]?("HO"F1I9F8@+75R3G @
M9V-C+6]R:6<O9V-C+V-O;F9I9R]M:6-R;V)L87IE+W0M;6EC<F]B;&%Z92!G
M8V,O9V-C+V-O;F9I9R]M:6-R;V)L87IE+W0M;6EC<F]B;&%Z90HM+2T@9V-C
M+6]R:6<O9V-C+V-O;F9I9R]M:6-R;V)L87IE+W0M;6EC<F]B;&%Z90DR,# W
M+3 V+3(P(#$S.C0S.C,T+C P,# P,# P," M,#<P, HK*RL@9V-C+V=C8R]C
M;VYF:6<O;6EC<F]B;&%Z92]T+6UI8W)O8FQA>F4),C P-RTP-BTR," Q-#HS
M-CHR-2XP,# P,# P,# @+3 W,# *0$ @+3,W+#,@*S,W+#0@0$ @355,5$E,
M24)?15A#15!424].4R ]("IM>&PM8F%R<F5L+7-H:69T+PH@(R,@56YF;W)T
M=6YA=&5L>2P@=&AI<R!D;V5S(&YO="!W;W)K+B!792!H879E('1O(&9I;F0@
M82!W87D@=&\@9&\@=&AI<RX@"B C(R!/=&AE<G=I<V4L("UX;"UB;&%Z96ET
M('=I;&P@8V%U<V4@;VYL>2!T:&4@8F%S92!L:6)G8V,@=&\@8F4@<&EC:V5D
M('5P(&%L=V%Y<RX*(",C($U53%1)3$E"7TU!5$-(15,@/2!:>&PM8FQA>F5I
M=#UM>&PM8F%R<F5L+7-H:69T(%IX;"UB;&%Z96ET/6UN;RUX;"US;V9T+6UU
$; HK"@``
`
end
begin 666 binutils_mb_lin64-2.patch
M9&EF9B M=7).<"!B:6YU=&EL<RUO<FEG+V=A<R]C;VYF:6<O=&,M;6EC<F]B
M;&%Z92YC(&)I;G5T:6QS+V=A<R]C;VYF:6<O=&,M;6EC<F]B;&%Z92YC"BTM
M+2!B:6YU=&EL<RUO<FEG+V=A<R]C;VYF:6<O=&,M;6EC<F]B;&%Z92YC"3(P
M,#<M,#8M,C @,38Z,S4Z,#<N,# P,# P,# P("TP-S P"BLK*R!B:6YU=&EL
M<R]G87,O8V]N9FEG+W1C+6UI8W)O8FQA>F4N8PDR,# W+3 W+3$R(#$U.C(X
M.C0T+C P,# P,# P," M,#<P, I 0" M,C,V.2PV("LR,S8Y+#$P($! (&UD
M7VYU;6)E<E]T;U]C:&%R<R H8VAA<B J('!T<BP@=F%L=654('4*(" @(&EF
M("@A('1A<F=E=%]B:6=?96YD:6%N*0H@(" @(" @<W=I=&-H("AN8GET97,I
M"B @(" @("!["BL@(" @("!C87-E(#@Z('!T<ELW72 ]("AU<V4@/CX@-38I
M("8@,'AF9CL**R @(" @(" @(" @(" @<'1R6S9=(#T@*'5S92 ^/B T."D@
M)B P>&9F.PHK(" @(" @(" @(" @("!P=');-5T@/2 H=7-E(#X^(#0P*2 F
M(#!X9F8["BL@(" @(" @(" @(" @('!T<ELT72 ]("AU<V4@/CX@,S(I("8@
M,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"B @(" @("!C87-E(#0Z('!T<ELS
M72 ]("AU<V4@/CX@,C0I("8@,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"B @
M(" @("!C87-E(#,Z('!T<ELR72 ]("AU<V4@/CX@,38I("8@,'AF9CL@+RH@
M9F%L;"!T:')O=6=H("HO"B @(" @("!C87-E(#(Z('!T<ELQ72 ]("AU<V4@
M/CX@(#@I("8@,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"D! ("TR,S<X+#8@
M*S(S.#(L,3 @0$ @;61?;G5M8F5R7W1O7V-H87)S("AC:&%R("H@<'1R+"!V
M86QU950@=0H@(" @96QS90H@(" @(" @<W=I=&-H("AN8GET97,I"B @(" @
M("!["BL@(" @("!C87-E(#@Z("IP='(K*R ]("AU<V4@/CX@-38I("8@,'AF
M9CL@"BL@(" @(" @(" @(" @("IP='(K*R ]("AU<V4@/CX@-#@I("8@,'AF
M9CL**R @(" @(" @(" @(" @*G!T<BLK(#T@*'5S92 ^/B T,"D@)B P>&9F
M.PHK(" @(" @(" @(" @(" J<'1R*RL@/2 H=7-E(#X^(#,R*2 F(#!X9F8[
M("\J(&9A;&P@=&AR;W5G:" J+R @(" @(" @(" @(" @"B @(" @("!C87-E
M(#0Z("IP='(K*R ]("AU<V4@/CX@,C0I("8@,'AF9CL@+RH@9F%L;"!T:')O
M=6=H("HO"B @(" @("!C87-E(#,Z("IP='(K*R ]("AU<V4@/CX@,38I("8@
M,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"B @(" @("!C87-E(#(Z("IP='(K
K*R ]("AU<V4@/CX@(#@I("8@,'AF9CL@+RH@9F%L;"!T:')O=6=H("HO"@``
`
end
begin 666 binutils_mb_lin64.patch
M9&EF9B M=7).<"!B:6YU=&EL<RUO<FEG+V=A<R]C;VYF:6<O=&,M;6EC<F]B
M;&%Z92YC(&)I;G5T:6QS+V=A<R]C;VYF:6<O=&,M;6EC<F]B;&%Z92YC"BTM
M+2!B:6YU=&EL<RUO<FEG+V=A<R]C;VYF:6<O=&,M;6EC<F]B;&%Z92YC"3(P
M,#<M,#8M,3D@,3 Z-3<Z,S0N,# P,# P,# P("TP-S P"BLK*R!B:6YU=&EL
M<R]G87,O8V]N9FEG+W1C+6UI8W)O8FQA>F4N8PDR,# W+3 V+3$Y(#$Q.C0V
M.C0U+C P,# P,# P," M,#<P, I 0" M,3 U-BPY("LQ,#4V+#$P($! ('!A
M<G-E7VEM;2 H8VAA<B J(',L(&5X<')E<W-I;VY3("H@92P@:6X*(" @(&5L
M<V4@:68@*"AE+3Y87V]P("$]($]?8V]N<W1A;G0@)B8@92T^6%]O<" A/2!/
M7W-Y;6)O;"D@*0H@(" @(" @+RH)(" @?'P@*&4M/EA?;W @/3T@3U]S>6UB
M;VP@(" F)B!E+3Y87V%D9%]N=6UB97(@(3T@," I*2 J+PH@(" @(" @87-?
M8F%D*%\H(F]P97)A;F0@;75S="!B92!A(&-O;G-T86YT(&]R(&$@;&%B96PB
M*2D["BT@("!E;'-E(&EF("@H92T^6%]O<" ]/2!/7V-O;G-T86YT*2 F)B H
M92T^6%]A9&1?;G5M8F5R(#P@;6EN('Q\(&4M/EA?861D7VYU;6)E<B ^(&UA
M>"DI"BL@("!E;'-E(&EF("@H92T^6%]O<" ]/2!/7V-O;G-T86YT*2 F)B H
M*&EN="D@92T^6%]A9&1?;G5M8F5R(#P@;6EN('Q\("AI;G0I(&4M/EA?861D
M7VYU;6)E<B ^(&UA>"DI('L*(" @(" @(&%S7V)A9" H7R@B;W!E<F%N9"!M
M=7-T(&)E(&%B<V]L=71E(&EN(')A;F=E("5D+BXE9"P@;F]T("5D(BDL"B @
M(" @(" @(" @(" @(&UI;BP@;6%X+" H:6YT*2!E+3Y87V%D9%]N=6UB97(I
M.PHK(" @?0H@"B @("!R971U<FX@;F5W.PH@?0ID:69F("UU<DYP(&)I;G5T
M:6QS+6]R:6<O;W!C;V1E<R]M:6-R;V)L87IE+6]P8RYH(&)I;G5T:6QS+V]P
M8V]D97,O;6EC<F]B;&%Z92UO<&,N: HM+2T@8FEN=71I;',M;W)I9R]O<&-O
M9&5S+VUI8W)O8FQA>F4M;W!C+F@),C P-RTP-BTQ.2 Q,#HU-SHT,RXP,# P
M,# P,# @+3 W,# **RLK(&)I;G5T:6QS+V]P8V]D97,O;6EC<F]B;&%Z92UO
M<&,N: DR,# W+3 V+3$Y(#$Q.C$Q.C$S+C P,# P,# P," M,#<P, I 0" M
M-# P+#$T("LT,# L,30@0$ @8VAA<B!P=G)?<F5G:7-T97)?<')E9FEX6UT@
M/2 B<G!V<B(["B *( H@+RH@(V1E9FEN97,@9F]R('9A;&ED(&EM;65D:6%T
M92!R86YG92 J+PHM(V1E9FEN92!-24Y?24U-(" P>#@P,# P,# P"BTC9&5F
M:6YE($U!6%])34T@(#!X-V9F9F9F9F8@"BLC9&5F:6YE($U)3E])34T@("@H
M:6YT*2 P>#@P,# P,# P*0HK(V1E9FEN92!-05A?24U-(" H*&EN="D@,'@W
M9F9F9F9F9BD*( HM(V1E9FEN92!-24Y?24U--R @,'@P,# *+2-D969I;F4@
M34%87TE-33<@(#!X-V9F"BLC9&5F:6YE($U)3E])34TW("@H:6YT*2 P># P
M,"D**R-D969I;F4@34%87TE-33<@*"AI;G0I(#!X-V9F*0H@"BTC9&5F:6YE
M($U)3E])34TQ-2 @,'@P,# P"BTC9&5F:6YE($U!6%])34TQ-2 @,'@Q9F9F
M"BLC9&5F:6YE($U)3E])34TQ-2 H*&EN="D@,'@P,# P*0HK(V1E9FEN92!-
M05A?24U-,34@*"AI;G0I(#!X,69F9BD*( H@(V5N9&EF("\J($U)0U)/0DQ!
,6D5?3U!#("HO"B *
`
end
Article: 124144I wrote: > If the EEPROM bytes start as 0x00, and individual bits can be changed from > zero to ones without having to erase the byte first, instead of incrementing > the EEPROM byte you would use a progression like 00->01->03->07->0f etc., > so you get eight "increments" of a byte value with no erase, and in doing so > only use up one unit of write endurance for that byte. dick <dick_12345678@hotmail.com> writes: > don't use binary coding but unary coding. That's what I wrote, though for a large counter, you don't want to exclusively use unary, because it will require too much space. A combination of unary code at the byte level with a gray code addressing scheme works quite nicely.Article: 124145
>glitches. The typical write operation is: > >1. change address. I think you also need something like: 1.5: Wait for new address to settle >2. toggle write signal to write data. >Gray code avoids glitches in a different way. It avoids glitches by >ensuring that only a single bit changes when the address change. This >allows us to do everything in a single clock cycle: > >(write signal is always set) >1. change address and write data. 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 -- These are my opinions, not necessarily my employer's. I hate spam.Article: 124146
On Sep 12, 2:20 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > > Have you thought about what happens to bus2ip_data before the magic > > address is hit? What about after it has been hit? > > No, I had not thought of it. I was just correcting the obvious > lack of a clk if-then and hopefully explaining why he got zeroes. > Perhaps, there is another driver. > > > What else (if anything) is driving bus2ip_data? If nothing, > > bus2ip_data will be (others => 'U') before, and X"FF00FF00" after, > > forevermore. > > > If something else is driving data, then a (others => 'X') will almost > > certainly result. > > > Andy Sorry Brad, my reply was meant for the OP instead of you. AndyArticle: 124147
I need the FIFO36 entity for XAPP851 (DDR SDRAM Controller Using Virtex-5 FPGA Devices). Either it wasn't in the zip file or I lost it while unzipping it. Thanks in advance, Brad Smallridge AiVisionArticle: 124148
On second look, it cound be that FIFO36 is part of the unisim library? Then why don't I have it? Is it because I'm running ISE 7.1? Or is it that the Web release doesn't support it? Is it part of Synplicity? Brad SmallridgeArticle: 124149
Brad Smallridge wrote: > On second look, it cound be that FIFO36 > is part of the unisim library? > Then why don't I have it? > Is it because I'm running ISE 7.1? > Or is it that the Web release doesn't support it? > Is it part of Synplicity? > > Brad Smallridge > > > 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
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