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 Wednesday, December 3, 2014 12:16:26 AM UTC-5, rickman wrote: > On 12/2/2014 11:27 PM, Rick C. Hodgin wrote: > > On Tuesday, December 2, 2014 11:16:29 PM UTC-5, rickman wrote: > >> On 12/2/2014 11:10 PM, Rick C. Hodgin wrote: > >>> On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote: > >>>> On 12/2/2014 10:45 PM, Rick C. Hodgin wrote: > >>>>> It is enough to live this way for the Lord. > >>>> > >>>> So what is guiding your technical decisions in designing this > >>>> processor? > >>>> For example, why 40 bits? Isn't that going to make some features > >>>> of the 386 difficult or impossible to implement? > >>> > >>> https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png > >>> > >>> 40-bits takes you to 1 Terabyte. If more is needed later, the > >>> LibSF 386-x48 can be created. > >> > >> So you have a requirement for 1 TB of address space. What are your > >> other requirements, but more importantly, what is driving those > >> requirements? > > > > I have no particular hardware requirements except that from the ground > > up it be a love offering unto the Lord. I have a background in x86 > > space from before I was a Christian, and I'm taking that knowledge > > forward, coupled with the things I've wanted or wished for in x86 > > space throughout my career. > > > > Ultimately I desire to have a CPU, all motherboard resources, any > > BIOS or firmware, the kernel, operating system, and all end-user > > software, be created from the LibSF offerings, with all of it being > > given unto the world without restriction, as a foundation or base > > upon which to build. > > I'm not familiar with LibSF. I assume you don't mean, "Libsf is a stack > fingerprinting library" which I found on the web. It's not important. > > I would like to be able to work with 14nm process technologies, and > > create CPUs that would outperform anything that exists ... but it's > > not the place the Lord has me. I am Rick C. Hodgin from Indiana. > > No riches. No skills in such things. I am waiting for others to > > come forward and offer up those things which they have in a similar > > way so that we can walk together, arm in arm, for the Lord. I > > believe very strongly that we could give unto the world as good or > > better as anything else that's out there because we'd be serving > > the Lord, listening to Him, doing what we do for Him, not taking > > shortcuts, not being pressed for quarterly fiscal deadlines, but > > rather being able to do it right because it's our best we desire > > to give. > > That's the part I don't understand. Here you say you are, "listening to > Him", but how does that turn into defining a CPU? Why/how is the CPU you > are designing any better for "Him" or anyone else than any other CPU you > might design? It relates back to the nature of the offer, as it comes from the inner drive of love and the offering of the things we posses given back unto Him by our heart's desire. > > It's up to Him though. I've been working on this project for over > > 28 months. I haven't found anyone to help me yet, though several > > people have been interested at various times, none of them had the > > necessary C/C++ coding skills to contribute. I've contacted > > Christian universities, posted on forums, etc. But, I am hopeful. > > :-) > > Maybe if you find a way to express the motivation and the guiding > principles so that others can understand. They're there. Best regards, Rick C. HodginArticle: 157401
On 12/3/2014 12:45 AM, Rick C. Hodgin wrote: > On Wednesday, December 3, 2014 12:16:26 AM UTC-5, rickman wrote: >> On 12/2/2014 11:27 PM, Rick C. Hodgin wrote: >>> On Tuesday, December 2, 2014 11:16:29 PM UTC-5, rickman wrote: >>>> On 12/2/2014 11:10 PM, Rick C. Hodgin wrote: >>>>> On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote: >>>>>> On 12/2/2014 10:45 PM, Rick C. Hodgin wrote: >>>>>>> It is enough to live this way for the Lord. >>>>>> >>>>>> So what is guiding your technical decisions in designing this >>>>>> processor? >>>>>> For example, why 40 bits? Isn't that going to make some features >>>>>> of the 386 difficult or impossible to implement? >>>>> >>>>> https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png >>>>> >>>>> 40-bits takes you to 1 Terabyte. If more is needed later, the >>>>> LibSF 386-x48 can be created. >>>> >>>> So you have a requirement for 1 TB of address space. What are your >>>> other requirements, but more importantly, what is driving those >>>> requirements? >>> >>> I have no particular hardware requirements except that from the ground >>> up it be a love offering unto the Lord. I have a background in x86 >>> space from before I was a Christian, and I'm taking that knowledge >>> forward, coupled with the things I've wanted or wished for in x86 >>> space throughout my career. >>> >>> Ultimately I desire to have a CPU, all motherboard resources, any >>> BIOS or firmware, the kernel, operating system, and all end-user >>> software, be created from the LibSF offerings, with all of it being >>> given unto the world without restriction, as a foundation or base >>> upon which to build. >> >> I'm not familiar with LibSF. I assume you don't mean, "Libsf is a stack >> fingerprinting library" which I found on the web. > > It's not important. > >>> I would like to be able to work with 14nm process technologies, and >>> create CPUs that would outperform anything that exists ... but it's >>> not the place the Lord has me. I am Rick C. Hodgin from Indiana. >>> No riches. No skills in such things. I am waiting for others to >>> come forward and offer up those things which they have in a similar >>> way so that we can walk together, arm in arm, for the Lord. I >>> believe very strongly that we could give unto the world as good or >>> better as anything else that's out there because we'd be serving >>> the Lord, listening to Him, doing what we do for Him, not taking >>> shortcuts, not being pressed for quarterly fiscal deadlines, but >>> rather being able to do it right because it's our best we desire >>> to give. >> >> That's the part I don't understand. Here you say you are, "listening to >> Him", but how does that turn into defining a CPU? Why/how is the CPU you >> are designing any better for "Him" or anyone else than any other CPU you >> might design? > > It relates back to the nature of the offer, as it comes from the > inner drive of love and the offering of the things we posses given > back unto Him by our heart's desire. Really? The technical decisions arise from a drive of love? That's hard to put in a requirements document. >>> It's up to Him though. I've been working on this project for over >>> 28 months. I haven't found anyone to help me yet, though several >>> people have been interested at various times, none of them had the >>> necessary C/C++ coding skills to contribute. I've contacted >>> Christian universities, posted on forums, etc. But, I am hopeful. >>> :-) >> >> Maybe if you find a way to express the motivation and the guiding >> principles so that others can understand. > > They're there. When you can express them in ways most people can understand and appreciate I expect you will find a few people who will join you. -- RickArticle: 157402
On 03/12/14 01:26, Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> I can't seem to find it now, but someone recently posted a link to >> price/LUT vs size data in graph form. It gets a bit crowded at the >> bottom end, but appears to show there is no real price difference >> between the two brands. The data does include a very small number of >> other devices than X and A, but not enough to be useful. > > Graphs again: > http://www.cl.cam.ac.uk/~atm26/pubs/FPL2014-ClusterInterconnect.pdf (page 2) > http://www.cl.cam.ac.uk/~atm26/ephemeral/fpga-pricing-2014-loglog.pdf > > I had data for ECP3 and Igloo 2. Most of the others that Digikey listed are > either very small (<20K LEs), missing LE data in their table, or legacy > products (APEX, XC4000, etc). There wasn't enough data to plot anything > reasonable from those. A graph of sub-20K devices would be interesting, but > it's a very different market. > >> In fact it is interesting that the prices get very crowded at the low >> end jamming up the graph. I suggested that he present the data with a >> logarithmic Y axis or even in log-log form. Clearly competitive market >> forces at work. > > One of the interesting things to note is the pricing margin between budget > and premium ranges: you pay 4-6x more per LE in a 'premium' family than in a > budget range. So if you can build a system with multiple FPGAs (and we > described a way to do that in the paper, which fits some applications better > than others) then it can be economic to use smaller budget FPGAs rather than > buy the premium FPGA. > > The alternative theory is that people buy budget FPGAs from Digikey, and > buying premium devices requires a long chat with a salesman, so the Digikey > list prices for those are mostly fiction that nobody pays. However the same > trend seems to apply across all vendors. > > Theo > There is also the point that the chips, especially the premium ones, include more than just logic elements - somewhere you will also be paying for hard core processors, fast transceivers, multi-port RAM, more I/O, etc. And different architectures have different ideas about what a logic element actually /is/. These sorts of things mean that a price-per-LE is only a simplistic comparison - although it is probably the best single figure that could be used here. But I expect that the main reason for the price margin is economy of scale - far more low-end FPGAs are produced than high-end ones, making production and testing costs very different.Article: 157403
On 02/12/14 20:56, glen herrmannsfeldt wrote: > rickman <gnuarm@gmail.com> wrote: > For RS232, the FPGA pins go to level converters to convert to the > appropriate voltages, but all the logic (UART) is in the FPGA. > I would recommend you use an FTDI USB chip instead of RS232 - it is easier, /much/ faster, and can connect to modern PC's that seldom have RS232 ports. An FTDI 4232H chip will give you up to 4 UARTs (or 2 UARTs and 2 SPI/I2C/JTAG) with something like 12 MBaud transmission rates.Article: 157404
On 12/3/2014 4:21 AM, David Brown wrote: > On 03/12/14 01:26, Theo Markettos wrote: >> rickman <gnuarm@gmail.com> wrote: >>> I can't seem to find it now, but someone recently posted a link to >>> price/LUT vs size data in graph form. It gets a bit crowded at the >>> bottom end, but appears to show there is no real price difference >>> between the two brands. The data does include a very small number of >>> other devices than X and A, but not enough to be useful. >> >> Graphs again: >> http://www.cl.cam.ac.uk/~atm26/pubs/FPL2014-ClusterInterconnect.pdf (page 2) >> http://www.cl.cam.ac.uk/~atm26/ephemeral/fpga-pricing-2014-loglog.pdf >> >> I had data for ECP3 and Igloo 2. Most of the others that Digikey listed are >> either very small (<20K LEs), missing LE data in their table, or legacy >> products (APEX, XC4000, etc). There wasn't enough data to plot anything >> reasonable from those. A graph of sub-20K devices would be interesting, but >> it's a very different market. >> >>> In fact it is interesting that the prices get very crowded at the low >>> end jamming up the graph. I suggested that he present the data with a >>> logarithmic Y axis or even in log-log form. Clearly competitive market >>> forces at work. >> >> One of the interesting things to note is the pricing margin between budget >> and premium ranges: you pay 4-6x more per LE in a 'premium' family than in a >> budget range. So if you can build a system with multiple FPGAs (and we >> described a way to do that in the paper, which fits some applications better >> than others) then it can be economic to use smaller budget FPGAs rather than >> buy the premium FPGA. >> >> The alternative theory is that people buy budget FPGAs from Digikey, and >> buying premium devices requires a long chat with a salesman, so the Digikey >> list prices for those are mostly fiction that nobody pays. However the same >> trend seems to apply across all vendors. >> >> Theo >> > > There is also the point that the chips, especially the premium ones, > include more than just logic elements - somewhere you will also be > paying for hard core processors, fast transceivers, multi-port RAM, more > I/O, etc. And different architectures have different ideas about what a > logic element actually /is/. These sorts of things mean that a > price-per-LE is only a simplistic comparison - although it is probably > the best single figure that could be used here. > > But I expect that the main reason for the price margin is economy of > scale - far more low-end FPGAs are produced than high-end ones, making > production and testing costs very different. Don't kid yourself. Yes, there will be some additional cost for I/O and the hard cores and even the more advanced LUT designs. I can assure you that "economy of scale" is not really the issue for any but the biggest devices. But that is largely in the noise when looking at a 60x range of cost per LUT. The high end is charging what the market will bear just as is true in nearly any market with constantly renewed products. -- RickArticle: 157405
rickman wrote: > Rick C. Hodgin wrote: > >> rickman wrote: > >> Maybe if you find a way to express the > >> motivation and the guiding principles so > >> that others can understand. > > They're there. > > When you can express them in ways most > people can understand and appreciate I > expect you will find a few people who will > join you. The people who come to this project will do so from within. It will be the same drive which moves me, which moves them -- an indwelling of His Holy Spirit, and a change, a desire to do the things we do, in whatever industry we're in, for Him. Some (most) will never be able to understand the drive there, nor see the value/gain in giving and sharing knowledge, sacrificing intellectual property rights so our fellow man might be able to create a better thing upon our prior work, etc. It is the nature of the division between born- again, and not born-again. It is why we need Jesus Christ, for without a faith in Him, a pursuit of Truth in our life, the flesh-based blindness prevents us from moving as we should. Jesus changes everything about a person's life. He fundamentally rewires everything about a person, from the inner thoughts to the inner drives. He is pervasive, and complete, and He opens our eyes to see the things we were blind to before. I urge you to seek Him, Rick. He will forgive you too, and change your life. Forever. Best regards, Rick C. HodginArticle: 157406
On 12/3/2014 6:00 AM, Rick C. Hodgin wrote: > rickman wrote: >> Rick C. Hodgin wrote: >>>> rickman wrote: >>>> Maybe if you find a way to express the >>>> motivation and the guiding principles so >>>> that others can understand. >>> They're there. >> >> When you can express them in ways most >> people can understand and appreciate I >> expect you will find a few people who will >> join you. > > The people who come to this project will do so > from within. It will be the same drive which > moves me, which moves them -- an indwelling > of His Holy Spirit, and a change, a desire to do > the things we do, in whatever industry we're in, > for Him. > > Some (most) will never be able to understand > the drive there, nor see the value/gain in giving > and sharing knowledge, sacrificing intellectual > property rights so our fellow man might be able > to create a better thing upon our prior work, > etc. I'm not questioning the drive. I'm asking how this effort is being led. I don't see where the decisions are coming from. For a project like this to succeed there has to be a basis from which the technical decisions are made. If it is all by the seat of your pants, that's fine, but it will be hard to find others who are willing to follow your lead. I think I understand this better now. Thanks. -- RickArticle: 157407
I have had long-term goals:
(1) Visual FreePro and its compiler framework
(2) Exodus 32-bit x86-based operating system
(3) Armodus 32-bit ARM-based OS.
(4) Exodus 64-bit.
(5) Armodus 64-bit
And various other related system and user apps.
I have only discovered in the last month that I
have some natural understanding of hardware.
Until this Oppie-1 project, I had always viewed
hardware as some distant and nebulous thing.
But now that I see I have this knowledge and
ability, much to my surprise I might add, I am
moving in this way.
It's absolutely floored me to be honest. When I
began to learn Verilog, and write things, and it
all made sense, I literally walked around my
house in disbelief saying out loud, "No way!"
And in the weeks since I've looled at how the
various hardware interconnects, and it's like this
veil has been lifted and I can see the hardware
ends.
The path before me is now a combined path:
(1) LibSF 386-x40 comprised of
(2) Exodus OS,
(3) Visual FreePro, and its general IDE supporting a C-like compiler, and
(4) Other user apps
Best regards,
Ricl C. Hodgin
Article: 157408
You can read my original goals here:
http://www.visual-freepro.org/forum/viewtopic.php?f=3&t=14
Best regards,
Rick C. Hodgin
Article: 157409On 03/12/14 13:05, Rick C. Hodgin wrote: > I have had long-term goals: > > (1) Visual FreePro and its compiler framework > (2) Exodus 32-bit x86-based operating system > (3) Armodus 32-bit ARM-based OS. > (4) Exodus 64-bit. > (5) Armodus 64-bit > > And various other related system and user apps. > > I have only discovered in the last month that I > have some natural understanding of hardware. > Until this Oppie-1 project, I had always viewed > hardware as some distant and nebulous thing. > But now that I see I have this knowledge and > ability, much to my surprise I might add, I am > moving in this way. > > It's absolutely floored me to be honest. When I > began to learn Verilog, and write things, and it > all made sense, I literally walked around my > house in disbelief saying out loud, "No way!" > Don't be so surprised - a basic understanding of digital logic is not actually very difficult. I was about 12 or 13 when I learned about boolean logic, registers, ALUs and processor design. If you are comfortable with binary, logic operations, and assembly code (on any cpu), then digital logic design is mostly pretty simple. There is an "ah-ha!" moment for software programmers when they first look at Verilog, VHDL, or other HDL's, when they realise you are mostly describing a lot of things that happen in parallel, rather than mostly describing a lot of things that happen serially, but you seem to have passed that. What is not simple, of course, is actually making something useful and working - figuring out what you need, how to make appropriate structures, how to manage everything, how to make the design efficient in size and space, how to avoid races, how to fit together existing pieces, etc. And even when you know what you are doing here, there is massive amounts of work involved. I am not trying to discourage you here - I am just saying that you shouldn't think you have some "natural aptitude" here (nor am I saying that you /don't/ have a natural aptitude - but if you do, it is not yet apparent). You are a reasonably intelligent person, with good enough mathematical skills and plenty of experience at assembly programming, and lots of determination and motivation - I would have been very surprised if you had /not/ got the hang of Verilog fairly quickly. > And in the weeks since I've looled at how the > various hardware interconnects, and it's like this > veil has been lifted and I can see the hardware > ends. > > The path before me is now a combined path: > > (1) LibSF 386-x40 comprised of > (2) Exodus OS, > (3) Visual FreePro, and its general IDE supporting a C-like compiler, and > (4) Other user apps > > Best regards, > Ricl C. Hodgin >Article: 157410
David, Jesus loves you. And I love you. Seek Him. Best regards, Rick C. HodginArticle: 157411
On 03/12/14 13:43, Rick C. Hodgin wrote: > David, > > Jesus loves you. And I love you. Seek Him. > > Best regards, > Rick C. Hodgin > Does that mean you agree with what I wrote? Or that you disagree? Or that you don't understand it? Or that you just don't want to think about it?Article: 157412
David, You are always writing posts to guide me in my endeavors. It is a good sentiment, and I wanted to do likewise. Your skills and knowledge are a great asset. Use them wisely. Best regards, Rick C. HodginArticle: 157413
rickman wrote: > I can't seem to find it now, but someone recently posted a link to > price/LUT vs size data in graph form. It gets a bit crowded at the > bottom end, but appears to show there is no real price difference > between the two brands. The data does include a very small number of > other devices than X and A, but not enough to be useful. > > In fact it is interesting that the prices get very crowded at the low > end jamming up the graph. I suggested that he present the data with a > logarithmic Y axis or even in log-log form. Clearly competitive market > forces at work. > The "low end" is where I live! So, I don't know about those $18,000 FPGAs, or who the heck USES them. I know that in very small quantities, the Xilinx XC3S50A is down to $6.12! This is pretty amazing! The non-volatile version of the part (XC3S50AN) is $9.91. These prices have actually come DOWN sometime this year! I have no idea what an equivalent Altera part would cost, due to the apples vs. oranges of different internal architecture. JonArticle: 157414
rickman wrote: > I can't seem to find it now, but someone recently posted a link to > price/LUT vs size data in graph form. It gets a bit crowded at the > bottom end, but appears to show there is no real price difference > between the two brands. The data does include a very small number of > other devices than X and A, but not enough to be useful. > > In fact it is interesting that the prices get very crowded at the low > end jamming up the graph. I suggested that he present the data with a > logarithmic Y axis or even in log-log form. Clearly competitive market > forces at work. > Spartan 3 is not included in the chart. In the log-log version (THANKS, Theo!) it is clear that the Spartan 6 does VERY well against most other types in the price/LUT. And, Virtex 5 is just about the WORST! You can't compare Spartan 3 vs. Spartan 6 due to the significant changes in the LUT capacity, unless you have some kind of correction factor to apply. I have NO IDEA how one would establish such a factor, though! JonArticle: 157415
Jon Elson wrote: > rickman wrote: > > >> I can't seem to find it now, but someone recently posted a link to >> price/LUT vs size data in graph form. It gets a bit crowded at the >> bottom end, but appears to show there is no real price difference >> between the two brands. The data does include a very small number of >> other devices than X and A, but not enough to be useful. >> >> In fact it is interesting that the prices get very crowded at the low >> end jamming up the graph. I suggested that he present the data with a >> logarithmic Y axis or even in log-log form. Clearly competitive market >> forces at work. >> > Spartan 3 is not included in the chart. In the log-log version > (THANKS, Theo!) it is clear that the Spartan 6 does VERY well against > most other types in the price/LUT. > > And, Virtex 5 is just about the WORST! > > You can't compare Spartan 3 vs. Spartan 6 due to the significant changes > in the LUT capacity, unless you have some kind of correction factor > to apply. I have NO IDEA how one would establish such a factor, though! > > Jon Sometime recently we went out for quotes on Spartan 6 and Artix 7 parts looking for the best price for a part with 4 GTP transceivers. The Artix-7 won that race, but the parts with fewer than 100K LE are still hard to get. The smallest Artix 7 (and possibly cheapest Xilinx FPGA) is the XC7A15T, which is only supported by the latest Vivado release and looks to be 15-18 weeks out. -- GaborArticle: 157416
Note that quite a few of the more expensive Altera eval boards ship with a "free" design tools DVD. The problem is, to actually use those design tools you need a license which is most definitely not free (possibly several times more expensive than the board itself) --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157417
On Wednesday, December 3, 2014 2:01:17 PM UTC-6, Jon Elson wrote:
> rickman wrote:
>
>
> > I can't seem to find it now, but someone recently posted a link to
> > price/LUT vs size data in graph form. It gets a bit crowded at the
> > bottom end, but appears to show there is no real price difference
> > between the two brands. The data does include a very small number of
> > other devices than X and A, but not enough to be useful.
> >
> > In fact it is interesting that the prices get very crowded at the low
> > end jamming up the graph. I suggested that he present the data with a
> > logarithmic Y axis or even in log-log form. Clearly competitive market
> > forces at work.
> >
> Spartan 3 is not included in the chart. In the log-log version
> (THANKS, Theo!) it is clear that the Spartan 6 does VERY well against
> most other types in the price/LUT.
>
> And, Virtex 5 is just about the WORST!
>
> You can't compare Spartan 3 vs. Spartan 6 due to the significant changes
> in the LUT capacity, unless you have some kind of correction factor
> to apply. I have NO IDEA how one would establish such a factor, though!
>
> Jon
Ran a number of opcores.org processor designs on Spartan 3&6, Kintex-7, Cyclone 2&4 and Arria II. ("http://opencores.org/project,up_core_list,downloads" pull "family comparison; numbers below are from a more recent version)
The LUT count averages are:
S-3: 1.46 4LUTs to one ALUT
S-6 & K-7: 1.05 6LUTs to one ALUT
C-2 & C-4: 1.58 4LUTs to one ALUT
So roughly 1.5 4LUTs per 6LUT or ALUT.
Fmax generally scales with process node
(altor32, atlas_2K-base, eco32, leros, m1_core, mblite, navre, next186, pic16c5x, pdp11-34verilob, risc5, t65 & tv80; typically 1K to 4K LUT designs)
Article: 157418
I ended up ordering this board:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830
I was informed in email today I should receive it early next week.
I'm going to spend some time getting communication working between the
FPGA and the host computer as a debugging feature of the Oppie-1 CPU.
I will modify my Oppie-1 Debugger to receive the debug data from the
live device and display it in execution as it goes, or step-by-step,
as it does presently in the simulation.
I will also be able to send/receive updates to memory locations, change
register values, reset, restart, a true remote debugging app.
Then ... on to Oppie-2.
-----
If anyone has advice on how to get communication running most easily
on this board, I would appreciate it. Thank you in advance.
Best regards,
Rick C. Hodgin
Article: 157419On 12/4/2014 12:25 PM, Rick C. Hodgin wrote: > I ended up ordering this board: > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830 > > I was informed in email today I should receive it early next week. > > I'm going to spend some time getting communication working between the > FPGA and the host computer as a debugging feature of the Oppie-1 CPU. > I will modify my Oppie-1 Debugger to receive the debug data from the > live device and display it in execution as it goes, or step-by-step, > as it does presently in the simulation. > > I will also be able to send/receive updates to memory locations, change > register values, reset, restart, a true remote debugging app. > > Then ... on to Oppie-2. > > ----- > If anyone has advice on how to get communication running most easily > on this board, I would appreciate it. Thank you in advance. Doesn't look like you have a lot of options on this board. UART serial to USB is the one comms choice. I thought you were going to use Ethernet. That seems to be another $250, wow, more than the FPGA board. I guess you can add one via the Arduino interface for next to nothing. -- RickArticle: 157420
On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote:
> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote:
> > I ended up ordering this board:
> > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830
> >
> > If anyone has advice on how to get communication running most easily
> > on this board, I would appreciate it. Thank you in advance.
>
> Doesn't look like you have a lot of options on this board. UART serial
> to USB is the one comms choice. I thought you were going to use
> Ethernet.
I plan to. I won't receive the PHY board I bought until the end of
December though. If there's another option I'll use that in the time
in-between, and possible after that.
I have one of the Silicon Labs chips arriving this week, but I'll need
to get a converter from its TQFP48 form factor to something usable by
human beings. I may go ahead and do that anyway. The Silicon Labs API
is very clean and straight-forward.
http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx
> That seems to be another $250, wow, more than the FPGA board.
> I guess you can add one via the Arduino interface for next to
> nothing.
Best regards,
Rick C. Hodgin
Article: 157421On 12/4/2014 6:00 PM, Rick C. Hodgin wrote: > On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote: >> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote: >>> I ended up ordering this board: >>> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830 >>> >>> If anyone has advice on how to get communication running most easily >>> on this board, I would appreciate it. Thank you in advance. >> >> Doesn't look like you have a lot of options on this board. UART serial >> to USB is the one comms choice. I thought you were going to use >> Ethernet. > > I plan to. I won't receive the PHY board I bought until the end of > December though. If there's another option I'll use that in the time > in-between, and possible after that. > > I have one of the Silicon Labs chips arriving this week, but I'll need > to get a converter from its TQFP48 form factor to something usable by > human beings. I may go ahead and do that anyway. The Silicon Labs API > is very clean and straight-forward. > > http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx I'm not keeping up with your choices. Why would you buy a chip that isn't on a board? Why not use the Arduino interface? I'm sure you can get Ethernet MAC modules for next to nothing. -- RickArticle: 157422
On Thursday, December 4, 2014 6:06:51 PM UTC-5, rickman wrote: > > I have one of the Silicon Labs chips arriving this week, but I'll need > > to get a converter from its TQFP48 form factor to something usable by > > human beings. I may go ahead and do that anyway. The Silicon Labs API > > is very clean and straight-forward. > > > > http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx > > I'm not keeping up with your choices. Why would you buy a chip that > isn't on a board? Why not use the Arduino interface? I'm sure you can > get Ethernet MAC modules for next to nothing. It was free. I ordered it as a sample. Best regards, Rick C. HodginArticle: 157423
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > I'm going to spend some time getting communication working between the > FPGA and the host computer as a debugging feature of the Oppie-1 CPU. > I will modify my Oppie-1 Debugger to receive the debug data from the > live device and display it in execution as it goes, or step-by-step, > as it does presently in the simulation. > > I will also be able to send/receive updates to memory locations, change > register values, reset, restart, a true remote debugging app. > > Then ... on to Oppie-2. > > ----- > If anyone has advice on how to get communication running most easily > on this board, I would appreciate it. Thank you in advance. There are two Altera components that might be useful: The JTAG UART is something that looks like a UART device, but runs via JTAG which is connected to your PC using USB. That means it's very simple to get a text terminal up from your FPGA. It isn't a 16550-style UART, it has a somewhat simpler interface (and if you're using a NIOS-II processor Altera's tools generate libraries so that printf() etc works). That means you don't need any extra hardware to get a serial port - you just run 'nios2-terminal' on your PC and you get a console of whatever comes out of the JTAG UART. System Console is an Altera (Java) app that allows you to get debug access to your FPGA, assuming your FPGA uses AXI or Altera's Avalon interconnect, which can be built with Altera's Qsys GUI tool for building systems-on-chip. Your components have AXI or Avalon interfaces, and you join them together in Qsys GUI (wiring up buses, interrupts, setting addresses, etc). Qsys synthesises a network on chip for you that implements the interconnect you wanted (so the 'buses' are actually packet switched networks). Once you've done that you can just drop in a debug module that allows access to those buses from System Console via JTAG via USB. In System Console on your PC you can write TCL scripts to access memory, change peripheral registers, etc. Since it's plugged into your existing interconnect it can access whatever is connected to it. In our case we have both System Console and a CPU debug unit. The debug unit is inside the CPU and allows insertion of instructions into the pipeline, which means we can force it to execute code to set registers etc. We use both that mechanism and System Console to access memory. The debug unit is implemented using a JTAG UART, but using it as a pipe to convey debug instructions rather than as a text terminal (we have another JTAG UART as the console). I'd suggest first taking the example projects supplied with the board, which use the NIOS-II CPU, and making yourself familiar with the toolchain: Quartus compilation Megawizard [1] Qsys (system-on-chip generator) NIOS-II bare-metal software world (Eclipse editor, C compiler, Board Support Package (BSP) of drivers for the FPGA hardware) Programming and only then go 'off piste'. For an example, this is the FPGA practical course that I teach that goes through the basics (from no HDL experience to building a heterogenous multicore system-on-chip in 24 hours of lab time): http://www.cl.cam.ac.uk/teaching/1415/ECAD+Arch/labs/ You don't have the same board but many of the concepts should still apply. Theo [1] Megawizard (a tool for configuring standalone IP blocks such as PLLs) is being phased out and rolled into Qsys, but it's still relevant at the momentArticle: 157424
On 12/4/2014 6:18 PM, Rick C. Hodgin wrote: > On Thursday, December 4, 2014 6:06:51 PM UTC-5, rickman wrote: >>> I have one of the Silicon Labs chips arriving this week, but I'll need >>> to get a converter from its TQFP48 form factor to something usable by >>> human beings. I may go ahead and do that anyway. The Silicon Labs API >>> is very clean and straight-forward. >>> >>> http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx >> >> I'm not keeping up with your choices. Why would you buy a chip that >> isn't on a board? Why not use the Arduino interface? I'm sure you can >> get Ethernet MAC modules for next to nothing. > > It was free. I ordered it as a sample. Why would you *order* a chip that isn't on a board? I have lots of "sample" chips I've never used because they aren't on a board. -- Rick
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