Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Jan 10, 8:19=A0am, "buddylee9898" <andrewludwig1@n_o_s_p_a_m.gmail.com> wrote: > Hello everyone, I have recently begun a project in which I would like to > add an Ethernet interface to my spartan-3e FPGA allowing it to receive > commands from one of two computers on a local network. Currently, I am > using the Digilent Basys 2 starter board along with the pmod Ethernet NIC > offered by Digilent. This pmod contains a PHY/MAC chip with an SPI > interface. > Oh boy. > My question relates to the needed coding on the FPGA. I have been searchi= ng > around and found that many people use Microblaze to simulate a > microprocessor on the FPGA, however I am largely unfamiliar with this and The MicroBlaze does not -simulate- a uProc. It *is* a uProc. You might want to start with a basic tutorial (Google is your friend) > was wondering if there was a way to use straight VHDL to simply receive > data from the PHY/MAC chip? Yes, yes there is. > From my understanding my device will not need > to use IP since I have no need to send data over the internet so I could > technically treat the PHY/MAC chip as a memory register that I would read > and write to, correct? Not correct. Not even close. You mentioned a "local network" above - you will need to support whatever protocol that network uses. The PmodNIC uses a MicroChip ENC28J60 - I suggest going to the MicroChip web site and learning all you can about that chip. > Thank you in advance. > > -Andrew >Article: 150326
On Mon, 10 Jan 2011 10:19:23 -0600, buddylee9898 wrote: > Hello everyone, I have recently begun a project in which I would like to > add an Ethernet interface to my spartan-3e FPGA allowing it to receive > commands from one of two computers on a local network. Currently, I am > using the Digilent Basys 2 starter board along with the pmod Ethernet > NIC offered by Digilent. This pmod contains a PHY/MAC chip with an SPI > interface. > > My question relates to the needed coding on the FPGA. I have been > searching around and found that many people use Microblaze to simulate a > microprocessor on the FPGA, however I am largely unfamiliar with this > and was wondering if there was a way to use straight VHDL to simply > receive data from the PHY/MAC chip? From my understanding my device will > not need to use IP since I have no need to send data over the internet > so I could technically treat the PHY/MAC chip as a memory register that > I would read and write to, correct? Thank you in advance. A simple alternative could be a Lantronix Xport. http://www.lantronix.com/device-networking/embedded-device-servers/ xport.html It allows a single TCP/IP connection through a serial interface. They're not cheap, but easy to use.Article: 150327
On Jan 9, 12:10=A0pm, mehdiru <me...@taileb.name> wrote: > Hello, > I'm looking for the Xilinx ML561 schematics. Please share! > > Thanks in advance I found them with Google, it really wasn't that hard. They are copyrighted require a license agreement with Xilinx to get. RK.Article: 150328
On Jan 10, 8:38=A0am, Tim Wescott <t...@seemywebsite.com> wrote: > > I'm not an =A0FPGA whiz, but I've done a bit of work in them. =A0Both tim= es > the problem said "processor", but the customer said "no processor". =A0Yo= u > end up with these gawdaful state machines that grow without bound, have > lots of synthesis gotchas (at least when I do them), and as a > consequence are maintenance nightmares. =A0At least when I do them I end > up with more lines of HDL than I would of assembly code to do it on a > processor. =A0Perhaps a better man than I could make these work and be > maintainable -- but perhaps a better man than I could just convince the > customer that yes, a processor is really what's needed. > > Were it me I would hesitate to make the mistake _again_, and I'd figure > that the up-front work of figuring out how to shove a processor in there > is going to be less than the subsequent work of maintaining a > processor-less nightmare of my own creation. > > -- > > Tim Wescott > Wescott Design Serviceshttp://www.wescottdesign.com > The picoBlaze started out as a state machine as you describe. From a certain abstraction, a state machine is a processor, so the "no processor" rule is broken. And besides, if the customer can't tell that you used a uBlaze/pico-Blaze/NIOS/etc, why tell them? I remember digging into a JTAG translation box done with a S3 expecting to be impressed with clever RTL only to find a uBlaze and a couple-hundred lines of "C". No way one could tell without inspecting the source code. RK PS - it's spelled godawful. :)Article: 150329
> How much parsing will you need to do of the information from the > PHY/MAC? If you just need to do some setup, then read from one memory > location over and over (which means that you'd be using low-level > Ethernet in some exceedingly simple fashion) then -- maybe. Essentially, the whole idea of the port is to be sending a constant stream of sensor data onto the network at about 8Mbps, and to receive commands to change which sensor the data will be coming from, so the sending of data is fairly constant while the receiving is not. > You mentioned a "local network" above - you will need to support > whatever protocol that network uses. Yes I will be using a local network which will contain a switch and two computers which will have custom software which should not have to use IP addressing, no? But I would like to get back to the point where d_s_klein said yes there is a way to receive straight data. I have read the data sheet for the ENC28J60, as well as data sheets for a few other chips I was considering, and in reading about them it seems fairly straightforward in that you are simply writing data to the chip (write command plus the packet data addresses, etc) and reading in a very similar way. Now I have tried to implement a state machine in order to have this working but without luck so far. Is this a silly way to try this where there is no way to avoid using the picoblaze, or is this feasible to some degree? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150330
On Mon, 10 Jan 2011 12:32:00 -0600, buddylee9898 wrote: > Yes I will be using a local network which will contain a switch and two > computers which will have custom software which should not have to use > IP addressing, no? But I would like to get back to the point where > d_s_klein said yes there is a way to receive straight data. I have read > the data sheet for the ENC28J60, as well as data sheets for a few other > chips I was considering, and in reading about them it seems fairly > straightforward in that you are simply writing data to the chip (write > command plus the packet data addresses, etc) and reading in a very > similar way. Now I have tried to implement a state machine in order to > have this working but without luck so far. Is this a silly way to try > this where there is no way to avoid using the picoblaze, or is this > feasible to some degree? If you can handle raw ethernet frames on your PC, these are fairly easy to generate/receive on the FPGA. All you need is a header with src/dst MAC, ethertype, and a CRC32 at the end. This can be done with a state machine. With a slightly more complicated state machine you can even handle IP/UDP, especially if you can hard wire the MAC addresses/router, or just switch src/dst MAC around on the reply. You can even leave out the ENC28J60 and talk directly to a PHY.Article: 150331
On Jan 10, 1:32=A0pm, "buddylee9898" <andrewludwig1@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > > How much parsing will you need to do of the information from the > > PHY/MAC? =A0If you just need to do some setup, then read from one memor= y > > location over and over (which means that you'd be using low-level > > Ethernet in some exceedingly simple fashion) then -- maybe. > > Essentially, the whole idea of the port is to be sending a constant strea= m > of sensor data onto the network at about 8Mbps, and to receive commands t= o > change which sensor the data will be coming from, so the sending of data = is > fairly constant while the receiving is not. > > > You mentioned a "local network" above - you will need to support > > whatever protocol that network uses. > > Yes I will be using a local network which will contain a switch =A0and tw= o > computers which will have custom software which should not have to use IP > addressing, no? But I would like to get back to the point where d_s_klein > said yes there is a way to receive straight data. I have read the data > sheet for the ENC28J60, as well as data sheets for a few other chips I wa= s > considering, and in reading about them it seems fairly straightforward in > that you are simply writing data to the chip (write command plus the pack= et > data addresses, etc) and reading in a very similar way. Now I have tried = to > implement a state machine in order to have this working but without luck = so > far. Is this a silly way to try this where there is no way to avoid using > the picoblaze, or is this feasible to some degree? =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com I can't say much about sending data over Ethernet, but be aware that the Picoblaze is a VERY minimal processor with a very minimal address space and program size. If you end up going that route, will it be any easier to write your own Picoblaze assembly code than designing your own HDL code? Is there any Picoblaze code available for this? I am pretty sure you can find code written for the MicroBlaze although it may be large enough that you will need external memory. RickArticle: 150332
On Jan 10, 11:38=A0am, Tim Wescott <t...@seemywebsite.com> wrote: > On 01/10/2011 08:19 AM, buddylee9898 wrote: > > > Hello everyone, I have recently begun a project in which I would like t= o > > add an Ethernet interface to my spartan-3e FPGA allowing it to receive > > commands from one of two computers on a local network. Currently, I am > > using the Digilent Basys 2 starter board along with the pmod Ethernet N= IC > > offered by Digilent. This pmod contains a PHY/MAC chip with an SPI > > interface. > > > My question relates to the needed coding on the FPGA. I have been searc= hing > > around and found that many people use Microblaze to simulate a > > microprocessor on the FPGA, however I am largely unfamiliar with this a= nd > > was wondering if there was a way to use straight VHDL to simply receive > > data from the PHY/MAC chip? From my understanding my device will not ne= ed > > to use IP since I have no need to send data over the internet so I coul= d > > technically treat the PHY/MAC chip as a memory register that I would re= ad > > and write to, correct? Thank you in advance. > > How much parsing will you need to do of the information from the > PHY/MAC? =A0If you just need to do some setup, then read from one memory > location over and over (which means that you'd be using low-level > Ethernet in some exceedingly simple fashion) then -- maybe. > > I'm not an =A0FPGA whiz, but I've done a bit of work in them. =A0Both tim= es > the problem said "processor", but the customer said "no processor". =A0Yo= u > end up with these gawdaful state machines that grow without bound, have > lots of synthesis gotchas (at least when I do them), and as a > consequence are maintenance nightmares. =A0At least when I do them I end > up with more lines of HDL than I would of assembly code to do it on a > processor. =A0Perhaps a better man than I could make these work and be > maintainable -- but perhaps a better man than I could just convince the > customer that yes, a processor is really what's needed. > > Were it me I would hesitate to make the mistake _again_, and I'd figure > that the up-front work of figuring out how to shove a processor in there > is going to be less than the subsequent work of maintaining a > processor-less nightmare of my own creation. Yes, you can always add a "processor" even if you don't call it a processor. I guess the real advantage of using a processor is that you can work in a language that suits the problem a bit better than a state machine. There is also the fact that much of the state is implied in the program counter rather than having to be explicit. I've rolled my own processor before and I can't say it saved me much work. I did it because I figured it was an investment, but it hasn't been used much since. If you had a state machine that consisted of a register which addressed memory containing the next state info would you be able to construct a language within VHDL that would simplify a complex state machine design? RickArticle: 150333
On 01/10/2011 11:00 AM, rickman wrote: > On Jan 10, 11:38 am, Tim Wescott<t...@seemywebsite.com> wrote: >> On 01/10/2011 08:19 AM, buddylee9898 wrote: >> >>> Hello everyone, I have recently begun a project in which I would like to >>> add an Ethernet interface to my spartan-3e FPGA allowing it to receive >>> commands from one of two computers on a local network. Currently, I am >>> using the Digilent Basys 2 starter board along with the pmod Ethernet NIC >>> offered by Digilent. This pmod contains a PHY/MAC chip with an SPI >>> interface. >> >>> My question relates to the needed coding on the FPGA. I have been searching >>> around and found that many people use Microblaze to simulate a >>> microprocessor on the FPGA, however I am largely unfamiliar with this and >>> was wondering if there was a way to use straight VHDL to simply receive >>> data from the PHY/MAC chip? From my understanding my device will not need >>> to use IP since I have no need to send data over the internet so I could >>> technically treat the PHY/MAC chip as a memory register that I would read >>> and write to, correct? Thank you in advance. >> >> How much parsing will you need to do of the information from the >> PHY/MAC? If you just need to do some setup, then read from one memory >> location over and over (which means that you'd be using low-level >> Ethernet in some exceedingly simple fashion) then -- maybe. >> >> I'm not an FPGA whiz, but I've done a bit of work in them. Both times >> the problem said "processor", but the customer said "no processor". You >> end up with these gawdaful state machines that grow without bound, have >> lots of synthesis gotchas (at least when I do them), and as a >> consequence are maintenance nightmares. At least when I do them I end >> up with more lines of HDL than I would of assembly code to do it on a >> processor. Perhaps a better man than I could make these work and be >> maintainable -- but perhaps a better man than I could just convince the >> customer that yes, a processor is really what's needed. >> >> Were it me I would hesitate to make the mistake _again_, and I'd figure >> that the up-front work of figuring out how to shove a processor in there >> is going to be less than the subsequent work of maintaining a >> processor-less nightmare of my own creation. > > > Yes, you can always add a "processor" even if you don't call it a > processor. I guess the real advantage of using a processor is that > you can work in a language that suits the problem a bit better than a > state machine. There is also the fact that much of the state is > implied in the program counter rather than having to be explicit. > > I've rolled my own processor before and I can't say it saved me much > work. I did it because I figured it was an investment, but it hasn't > been used much since. > > If you had a state machine that consisted of a register which > addressed memory containing the next state info would you be able to > construct a language within VHDL that would simplify a complex state > machine design? Did you realize that you were basically defining a processor in that last paragraph? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 150334
buddylee9898 <andrewludwig1@n_o_s_p_a_m.gmail.com> wrote: (snip) > My question relates to the needed coding on the FPGA. I have been searching > around and found that many people use Microblaze to simulate a > microprocessor on the FPGA, however I am largely unfamiliar with this and > was wondering if there was a way to use straight VHDL to simply receive > data from the PHY/MAC chip? From my understanding my device will not need > to use IP since I have no need to send data over the internet so I could > technically treat the PHY/MAC chip as a memory register that I would read > and write to, correct? UDP isn't so hard to do without a processor. If you put a static ARP entry on another host, then you don't need to do ARP inside your box. As someone else mentioned, you only need to exchange the source and destination addresses (and ports) to reply to a request. Last I knew, it was even possible to ignore the checksum for UDP. It used to be that Sun did that with NFS to speed it up, and, for a single LAN, to trust the ethernet CRC to catch errors. The UDP header is so simple that I don't see any reason to use RAW ethernet. (Well, if you are only sending between FPGA based boxes, and never any other host, then maybe.) -- glenArticle: 150335
On Jan 10, 10:19=A0am, "buddylee9898" <andrewludwig1@n_o_s_p_a_m.gmail.com> wrote: > Hello everyone, I have recently begun a project in which I would like to > add an Ethernet interface to my spartan-3e FPGA allowing it to receive > commands from one of two computers on a local network. Currently, I am > using the Digilent Basys 2 starter board along with the pmod Ethernet NIC > offered by Digilent. This pmod contains a PHY/MAC chip with an SPI > interface. > > My question relates to the needed coding on the FPGA. I have been searchi= ng > around and found that many people use Microblaze to simulate a > microprocessor on the FPGA, however I am largely unfamiliar with this and > was wondering if there was a way to use straight VHDL to simply receive > data from the PHY/MAC chip? From my understanding my device will not need > to use IP since I have no need to send data over the internet so I could > technically treat the PHY/MAC chip as a memory register that I would read > and write to, correct? Thank you in advance. > > -Andrew > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com From what you describe here and in other places in this thread you have several options. 1. Use a PicoBlaze and write a bit of assembly code for it to receive the commands. The PicoBlaze is small, about 100 slices and one block ram. Your data rates a low enough for it to deal with. You could just work at the Ethernet frame level, but UDP/IP is easily within the range of the PicoBlaze if you do not have to deal with reassembling fragmented packets. You say else where that you control the network, so you don't need to deal with ARP if you don't want to. Just set up static ARP table entries on the computers that need to communicate with your design. This is what I would recommend based on what you have written here. I have used the PicoBlaze to build a custom offload engine that diverted a custom protocol wrapped in UDP/IP on Gigabit Ethernet, and the PicoBlaze worked fine for that. 2. You could write VHDL state machines to deal with this if you want to. Its not hard, especially since you control the network, and can specify your own format. You could use UDP/IP, disallow fragmenting and IP options, and then all the MAC/IP addresses and port numbers would be at fixed offsets from the start of the frame. Just start a counter at the start of the frame, and match expected values at certain counts (ie protocol and destination address fields) and use the port number as a register address if you wish. Use static ARP table entries again, and you don't have to deal with that issue in the FPGA. UDP check sums can just be set to zero if you do not want to deal with them. I have used both methods, and if a PicoBlaze will do the job for you, I would use it. It is easier and quicker to make changes with it, and something always changes. If you need high throughput or low latency, that is when I would recommend HDL code. I did a demo to show how low of latency we could achieve in modifying a packet on the fly. The VHDL code filters out ICMP Echo request messages (ie a ping), and sends them back to the source as ICMP Echo reply messages. It needed 10 clock cycles to reorder addresses, and a few more for the interface to/from the MAC. The packet was being sent out while it was still coming in. Regards, John McCaskill www.FasterTechnology.com A Xilinx Authorized Training Provider, and Xilinx Alliance PartnerArticle: 150336
On Jan 10, 10:32=A0am, "buddylee9898" <andrewludwig1@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > > How much parsing will you need to do of the information from the > > PHY/MAC? =A0If you just need to do some setup, then read from one memor= y > > location over and over (which means that you'd be using low-level > > Ethernet in some exceedingly simple fashion) then -- maybe. > > Essentially, the whole idea of the port is to be sending a constant strea= m > of sensor data onto the network at about 8Mbps, and to receive commands t= o > change which sensor the data will be coming from, so the sending of data = is > fairly constant while the receiving is not. > > > You mentioned a "local network" above - you will need to support > > whatever protocol that network uses. > > Yes I will be using a local network which will contain a switch =A0and tw= o > computers which will have custom software which should not have to use IP > addressing, no? OK, fine. You will still need a protocol. You could use something line NetBUI, to avoid IP, but that seems like a lot of work to move backwards. > But I would like to get back to the point where d_s_klein > said yes there is a way to receive straight data. I have read the data > sheet for the ENC28J60, as well as data sheets for a few other chips I wa= s > considering, and in reading about them it seems fairly straightforward in > that you are simply writing data to the chip (write command plus the pack= et > data addresses, etc) and reading in a very similar way. Now I have tried = to > implement a state machine in order to have this working but without luck = so > far. Is this a silly way to try this where there is no way to avoid using > the picoblaze, or is this feasible to some degree? =A0 =A0 =A0 =A0 > I said it was possible. I did not say that it would be easy, or that I would do it that way. FWIW, I have done a full TCP/IP stack in RTL. At the data rates you're talking about, that makes no sense to do. There are complete TCP/IP solutions in a chip - I think you want that rather than a SPI-PHY. (Something like the WIZnet WIZ810MJ) RK.Article: 150337
On Jan 10, 12:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > UDP isn't so hard to do without a processor. =A0If you put a static ARP > entry on another host, then you don't need to do ARP inside your box. > > -- glen You still need IP for UDP.Article: 150338
On Jan 10, 2:46=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > On Jan 10, 12:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> > wrote: > > > > > UDP isn't so hard to do without a processor. =A0If you put a static ARP > > entry on another host, then you don't need to do ARP inside your box. > > > -- glen > > You still need IP for UDP. If you control the network and don't allow fragmented packets and don't use any of the IP options, there is very little that you need to do for IP. If you are receiving, just check the appropriate fields to see if the packet is what you are looking for. Ignore the checksum if you wish. If you are sending data, it can still be simple. When replying, if you just swap the source and destination address, you do not need to adjust the checksum. If originating data of constant length, build a static header in advance if you can. Then you just need to stick it on front of the data to send. The IP checksum is only for the header. Regards, John McCaskillArticle: 150339
On Jan 10, 9:01=A0am, d_s_klein <d_s_kl...@yahoo.com> wrote: > I found them with Google, it really wasn't that hard. > They are copyrighted require a license agreement with Xilinx to get. I thought they would be easy to find with Google also. I found a user manual, UG199, which did not include the schematics (except for an LCD interface), and a ZIP file of reference design files, which required the license agreement you describe, but did not include the board schematics. If you actually found the ML561 schematics, could you please give us a more specific pointer? Thanks! EricArticle: 150340
On Jan 10, 4:38=A0pm, Eric Smith <space...@gmail.com> wrote: > On Jan 10, 9:01=A0am, d_s_klein <d_s_kl...@yahoo.com> wrote: > > > I found them with Google, it really wasn't that hard. > > They are copyrighted require a license agreement with Xilinx to get. > > I thought they would be easy to find with Google also. =A0I found a user > manual, UG199, which did not include the schematics (except for an LCD > interface), and a ZIP file of reference design files, which required > the license agreement you describe, but did not include the board > schematics. =A0If you actually found the ML561 schematics, could you > please give us a more specific pointer? > > Thanks! > Eric According to the User Guide, you should have it on the CD that ships with the board. - You do have the board? Documentation and Reference Design CD The CD included in the Virtex-5 FPGA ML561 Memory Interfaces Tool Kit contains the design files for the Virtex-5 FPGA ML561 Development Board, including schematics, board layout, and reference design files. Open the ReadMe.rtf file on the CD to review the list of contents.Article: 150341
On Jan 10, 3:04 pm, Tim Wescott <t...@seemywebsite.com> wrote: > On 01/10/2011 11:00 AM, rickman wrote: > > > > > On Jan 10, 11:38 am, Tim Wescott<t...@seemywebsite.com> wrote: > >> On 01/10/2011 08:19 AM, buddylee9898 wrote: > > >>> Hello everyone, I have recently begun a project in which I would like to > >>> add an Ethernet interface to my spartan-3e FPGA allowing it to receive > >>> commands from one of two computers on a local network. Currently, I am > >>> using the Digilent Basys 2 starter board along with the pmod Ethernet NIC > >>> offered by Digilent. This pmod contains a PHY/MAC chip with an SPI > >>> interface. > > >>> My question relates to the needed coding on the FPGA. I have been searching > >>> around and found that many people use Microblaze to simulate a > >>> microprocessor on the FPGA, however I am largely unfamiliar with this and > >>> was wondering if there was a way to use straight VHDL to simply receive > >>> data from the PHY/MAC chip? From my understanding my device will not need > >>> to use IP since I have no need to send data over the internet so I could > >>> technically treat the PHY/MAC chip as a memory register that I would read > >>> and write to, correct? Thank you in advance. > > >> How much parsing will you need to do of the information from the > >> PHY/MAC? If you just need to do some setup, then read from one memory > >> location over and over (which means that you'd be using low-level > >> Ethernet in some exceedingly simple fashion) then -- maybe. > > >> I'm not an FPGA whiz, but I've done a bit of work in them. Both times > >> the problem said "processor", but the customer said "no processor". You > >> end up with these gawdaful state machines that grow without bound, have > >> lots of synthesis gotchas (at least when I do them), and as a > >> consequence are maintenance nightmares. At least when I do them I end > >> up with more lines of HDL than I would of assembly code to do it on a > >> processor. Perhaps a better man than I could make these work and be > >> maintainable -- but perhaps a better man than I could just convince the > >> customer that yes, a processor is really what's needed. > > >> Were it me I would hesitate to make the mistake _again_, and I'd figure > >> that the up-front work of figuring out how to shove a processor in there > >> is going to be less than the subsequent work of maintaining a > >> processor-less nightmare of my own creation. > > > Yes, you can always add a "processor" even if you don't call it a > > processor. I guess the real advantage of using a processor is that > > you can work in a language that suits the problem a bit better than a > > state machine. There is also the fact that much of the state is > > implied in the program counter rather than having to be explicit. > > > I've rolled my own processor before and I can't say it saved me much > > work. I did it because I figured it was an investment, but it hasn't > > been used much since. > > > If you had a state machine that consisted of a register which > > addressed memory containing the next state info would you be able to > > construct a language within VHDL that would simplify a complex state > > machine design? > > Did you realize that you were basically defining a processor in that > last paragraph? > > -- > > Tim Wescott > Wescott Design Serviceshttp://www.wescottdesign.com > > Do you need to implement control loops in software? > "Applied Control Theory for Embedded Systems" was written for you. > See details athttp://www.wescottdesign.com/actfes/actfes.html Yup, that was my point. It would have the same functionality, but if you can implement it in VHDL rather than adding the complexity of a separate tool to compile the code, it would be a lot simpler. My processor design was a zero operand machine which allowed the instructions to all be VHDL constants that I could use to define the contents of the memory array. Other than instructions, the only other info in the memory was constants like data and addresses. The only real issue I had with this processor was the way constants were built up. The instructions are 9 bits to match the width of FPGA memory and a constant just has the msb a zero. The first 8 bit constant is sign extended in the register and subsequent constant instructions cause each 8 bits to be shifted into the register from the right. The issue is that the size of a constant is not known until it is evaluated. If it is used for a jump and the size is not as expected, it can cause its own value to change. When multiple jumps affect one another, it can be very complex to figure out systematically. Otherwise, the processor is small, quick and the code easy to write. The next time I need a processor, I will return to working on this design. RickArticle: 150342
In article <e63ce504-f7cb-480c-87a1-ba8e45b121d4@p7g2000prb.googlegroups.com>, d_s_klein <d_s_klein@yahoo.com> writes: >On Jan 10, 12:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> >wrote: >> >> UDP isn't so hard to do without a processor. If you put a static ARP >> entry on another host, then you don't need to do ARP inside your box. >You still need IP for UDP. Not really if you are just responding to packets from the other system. You don't need ARP or routing. You just swap a few fields and send it back where it came from. Responding to ARP probes might be helpful. But then you have to know your IP address as well as your MAC address. It would be interesting to see how many lines of code in some abstract simple machine it takes to respond to a UDP packet that says roughly: What's the voltage on pin 3. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 150343
ok the issue has been resolved but i have no idea how.. Previously i was using xilinx 12.1 to synthesize and implement the code. And it was showing the behavior i posted in my first post. Today, just to check, i synthesized the same code on xilinx 9.1 and it worked. I have no idea why wasn't it working on xilinx 12.1, when both the RTLs are same. Has anyone else experienced this problem before ? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150344
>On 1/11/2011 7:06 AM, Hal Murray > It would be interesting to see how many lines of code > in some abstract simple machine it takes to respond to > a UDP packet that says roughly: What's the voltage on > pin 3. Quick & dirty UDP style: http://www.fpga4fun.com/10BASE-T.html Oviously a real product needs ARP and at least DHCP but...Article: 150345
"KJ" <kkjennings@sbcglobal.net> wrote in message news:872e6dca-2257-432c-95b7-1fc9ab2a0b09@m37g2000vbn.googlegroups.com... >On Jan 7, 4:07 am, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote: >> >> The code below is some tested and implemented code I found on my >> >> drive. >> NO, ieee.std_logic_arith.all was not in my code. Did you try it? >Yes, I did...apparently you did not, even though you called it "tested >and implemented code I found on my drive". > >Quartus 10.0 SP1 reports the following error on the statement >"testcnt<=testcnt+"1"; " >Error (10327): VHDL error at Junk.vhd(341): can't determine definition >of operator ""+"" -- found 0 possible definitions > >Modelsim 6.4 reports the following (as I mentioned in the first post) >No feasible entries for infix operator "+". > >But before you get those errors, you'll have to clean up another error >because you used the name 'test' as the name of the entity and as a >signal. > > architecture rtl of test is > ... > test<='0'; > >As I suggested in my first post, you might want to try out your code >first before posting. Alright, I admit changing the name of the entity after pasting, cause the original name was not related to the function. Also, what is missing in your attempt is: use ieee.std_logic_unsigned.all; Which I assumed was very common and didn't include. Sorry for that.Article: 150346
On Jan 10, 5:39=A0pm, Thomas Stanka <usenet_nospam_va...@stanka-web.de> wrote: > On 10 Jan., 11:47, F M <fmon...@gmail.com> wrote: > > > > > > > > > > > On Jan 10, 8:53=A0am, "karl.bengtsson" > > > <karl.bengtsson@n_o_s_p_a_m.n_o_s_p_a_m.norspace.no> wrote: > > > > Which part numbers have you actually seen this occur on ? > > > > My device is an A54SX32SA-208CQFP. A freshly burned A54SX32SA-208PQFP= shows > > > normal current consumption. > > > > I understand how leaving the voltage at an incorrect level will cause > > > current to flow in the input, which could cause excessive heating. > > > > But how would this translate into an permanent increase in current on= the > > > core supply? > > > > Some additional findings. I desoldered (well, someone did it for me) = the > > > VCCA pins of the FPGA to see if there where any difference between th= em. I > > > then connected them one-by-one and looked at the current delivered. A= few > > > of the pins showed a stable, high, current consumption. While a coupl= e of > > > others varied wildly for a few seconds before settling to the same, h= igh, > > > current consumption. > > > I have no idea if this tells anyone anything, but I felt it was worth > > > noting. > > > > Anyhow, thanks everyone for the replies so far! :) > > > > --------------------------------------- =A0 =A0 =A0 =A0 > > > Posted throughhttp://www.FPGARelated.com > > > It looks like that part was irradiated by particles during a test > > beam. > > This is a OTP FPGA. That Actel's family is used in the satellites/ > > rockets/airplane as also in particle physics experiments =A0and usually > > are submitted to radiation test. > > After radiation, one major TID effect is an augment of leakage current > > in CMOS that is what you observe. > > > So the question are: > > where this Ic come from ? > > Could it been irradiated ? > > > It is only a hypothesis but it is better to have care in managing that > > part. > > The A54xxx is the commercial device without radiation hardening. Would > not expect any irradiation of this device expecially not in device > screening process, as rad tests are not part of device screening only > qualification (means the design is irradiated, not the delivered > device). Screening should only cover a burn-in for each device (normal > for a RT54 device, don't know if some mil flow covers burn-in). > > For the RT54SXxxS devices from MEC there was an issue with inrush > during power cycling. Don't know if commercial device could have the > same issue as it is different silicon with AFAIK different process > than RT device. > > bye Thomas I think Karl knows very well that A54SX32A is commercial - not RT - part. In any case, A54SX are currently used in many radiation environments. Just try to google with "A54SX32A radiation". They are a compromise between robustness against radiation and costs. When you need thousand of parts it is really costly to purchase RT version. This is common in application like electronics for particle physics. I'm used to follow that way with flash A3P commercial (not RT) family. In this case, the RTA3P's silicon is exactly the same as the commercial A3P ones. Anyway I don't thinks this applies also to A54SX vs. RT54SX. Ususally RT OTP flash are tripled (TRM). Fully agree with the sentence as A54SX32A are OTP part. > as rad tests are not part of device screening only > qualification (means the design is irradiated, not the delivered > device). but pls be noticed that Karl does not explain the application on A54SX32A nor it is fully clear if he was really the engineer which programmed the part. Could have got it already programmed from someone else ? In this case, could a radiation test be done ? I currently work with A3P commercial parts which was irradiated time ago and now I'm making measurements on the leakage currents in order to understand 'end of life' behavior. This is fine with me as I know what I have in my hands. As I wrote, mine was only an hypothesis. The suggestion is to trace back from where that part comes. I'm convinced that this is really a far - not probable - possibility but errors and mistakes could have happened. It is up to Karl understand if this could be possible or not. It depends from where he works, who is his supplier and so on ... Anyway I'm sure that many other reasons could explain the part's behavior. Cheers, FabioArticle: 150347
[big snip] > >I'm not an FPGA whiz, but I've done a bit of work in them. Both times >the problem said "processor", but the customer said "no processor". You >end up with these gawdaful state machines that grow without bound, have >lots of synthesis gotchas (at least when I do them), and as a >consequence are maintenance nightmares. At least when I do them I end >up with more lines of HDL than I would of assembly code to do it on a >processor. Perhaps a better man than I could make these work and be >maintainable -- but perhaps a better man than I could just convince the >customer that yes, a processor is really what's needed. > >Were it me I would hesitate to make the mistake _again_, and I'd figure >that the up-front work of figuring out how to shove a processor in there >is going to be less than the subsequent work of maintaining a >processor-less nightmare of my own creation. > >-- > >Tim Wescott >Wescott Design Services >http://www.wescottdesign.com > I can think of a sensible reason for the "no-processor" requirement, where the client already does DO-254 compliant design, but does not have the infrastructure for DO-178 (despite DO-254 being derived from DO-178 in the writing...). So, *lots* of expense to them from adding "software". As to the OP's problem, the solution rather depends on whether they are going to make <10, ~1000, or >1E6 of them. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150348
>"KJ" <kkjennings@sbcglobal.net> wrote in message [snip] >Alright, I admit changing the name of the entity after pasting, cause the >original name was not related to the function. >Also, what is missing in your attempt is: >use ieee.std_logic_unsigned.all; >Which I assumed was very common and didn't include. Sorry for that. > Alas, use of ieee.std_logic_unsigned, rather than numeric_std, is all-too-common! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150349
Hi, I would like to implement an algorithm on a deconvolution for a Spartan6. Do you know some references of implementation or algorithm that me help in my task? Thank you
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