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
Hi, I am a 2nd-year ee student, and I need to make a term Project. With BAS= YS3 by using VHDL. My purpose is constructing a car which can be controlled with the buttons o= n BASYS3 ( I think I need Bluetooth module for it to RC a car). In addition= to that my car should stop when it sees red ( i think I should use a color= sensor for it) and should not work until it sees a green. These =E2=80=9Cr= ed=E2=80=9D and =E2=80=9Cgreen=E2=80=9D can be anything like green cubic to= ys. This color sensor does not have to be mounted on the car, but it would be b= etter if it is. I have very little information about basys3, vhdl, sensor design, etc. (thi= s is my first course in ee I was learning principle courses like math, phy,= cs ) I would appreciate any help. Thanks.Article: 161201
Hello Folks, I wanted to Implement Modbus Slave protocol with the use of only FPGA, without use of any external or internal softcore,Hardcore. Currently i have successfully Implemented Modbus Master protcol, Now I am Looking forward to bulit Modbus Slave as well. For Implementation Of Modbus Slave I am currently using Spartan6 FPGA and ISE 14.7 for For coding In VHDl. I want some help to know how should I start with Implementation,Coding n all. If possible share any document links as well. Again I don't want to use any softcore so please suggest answers related to given FPGA only, Thanks.Article: 161202
On Thursday, March 14, 2019 at 1:38:31 AM UTC-4, Swapnil Patil wrote: > Hello Folks, > > I wanted to Implement Modbus Slave protocol with the use of only FPGA, without use of any external or internal softcore,Hardcore. > > Currently i have successfully Implemented Modbus Master protcol, Now I am Looking forward to bulit Modbus Slave as well. > > For Implementation Of Modbus Slave I am currently using Spartan6 FPGA and ISE 14.7 for For coding In VHDl. > > I want some help to know how should I start with Implementation,Coding n all. > If possible share any document links as well. > > Again I don't want to use any softcore so please suggest answers related to given FPGA only, Thanks. I don't understand your problem. If you have implemented a Modbus master, it would seem that you should understand it well enough to implement the slave as well. Do you have any specific questions? Rick C.Article: 161203
I never designed slave before i have worked on master parts mostly. While designing for modbus slave which parameters should i should take into accounts. If somebody can explain the FSM flow? it would be great help. Thanks.Article: 161204
On Thursday, March 14, 2019 at 2:51:46 AM UTC-4, Swapnil Patil wrote: > I never designed slave before i have worked on master parts mostly. > While designing for modbus slave which parameters should i should take into accounts. > If somebody can explain the FSM flow? it would be great help. > Thanks. How does the master work? Rick C.Article: 161205
On Thursday, March 14, 2019 at 1:44:36 PM UTC+5:30, gnuarm.del...@gmail.com= wrote: > On Thursday, March 14, 2019 at 2:51:46 AM UTC-4, Swapnil Patil wrote: > > I never designed slave before i have worked on master parts mostly.=20 > > While designing for modbus slave which parameters should i should take = into accounts.=20 > > If somebody can explain the FSM flow? it would be great help. > > Thanks. >=20 > How does the master work?=20 >=20 > Rick C. First it calculates CRC and stores in register. Then i wrote FSM accordingl= y it first send slave address then function code, Data and at last CRC calc= ulated. i used r232 UART communication hence i send all the packets via UAR= T communication at 19200 baud rate. according to clock i adjusted my t1.5 and t3.5 timer to match timing in acc= ordance modbus slandered protocol. i checked output using slave simulator it works.Article: 161206
On 14/03/2019 08:47, Swapnil Patil wrote: > On Thursday, March 14, 2019 at 1:44:36 PM UTC+5:30, gnuarm.del...@gmail.com wrote: >> On Thursday, March 14, 2019 at 2:51:46 AM UTC-4, Swapnil Patil wrote: >>> I never designed slave before i have worked on master parts mostly. >>> While designing for modbus slave which parameters should i should take into accounts. >>> If somebody can explain the FSM flow? it would be great help. >>> Thanks. >> >> How does the master work? >> >> Rick C. > > First it calculates CRC and stores in register. Then i wrote FSM accordingly it first send slave address then function code, Data and at last CRC calculated. i used r232 UART communication hence i send all the packets via UART communication at 19200 baud rate. > according to clock i adjusted my t1.5 and t3.5 timer to match timing in accordance modbus slandered protocol. > i checked output using slave simulator it works. > As you don't appear to understand it at all, I'm guessing you copied the Modbus master design from elsewhere as well. How does the slave simulator work? You might find a few clues in that.Article: 161207
Okay First thing I haven't copied it. I wrote it myself. I know how master part works and I just explained how I designed it. And Secondly don't put posts just to show off, if you really want help give the solution if you really that smart enough..!!Article: 161208
On Thursday, March 14, 2019 at 4:47:35 AM UTC-4, Swapnil Patil wrote: > On Thursday, March 14, 2019 at 1:44:36 PM UTC+5:30, gnuarm.del...@gmail.c= om wrote: > > On Thursday, March 14, 2019 at 2:51:46 AM UTC-4, Swapnil Patil wrote: > > > I never designed slave before i have worked on master parts mostly.= =20 > > > While designing for modbus slave which parameters should i should tak= e into accounts.=20 > > > If somebody can explain the FSM flow? it would be great help. > > > Thanks. > >=20 > > How does the master work?=20 > >=20 > > Rick C. >=20 > First it calculates CRC and stores in register. Then i wrote FSM accordin= gly it first send slave address then function code, Data and at last CRC ca= lculated. i used r232 UART communication hence i send all the packets via U= ART communication at 19200 baud rate. > according to clock i adjusted my t1.5 and t3.5 timer to match timing in a= ccordance modbus slandered protocol. > i checked output using slave simulator it works. Based on that info I'm pretty sure I could design a slave. I'm not sure wh= at you mean by t1.5 and t3.5, but otherwise it seems pretty simple. What d= on't you understand about designing the slave?=20 One of the things I learned in computer programming was a good start to org= anizing your program is to determine what data structures your program will= need. HDL is not different. The data structures will be the registers ho= lding the data. You will need a UART receiver with a receiving register bu= t might not need the holding register since I expect all the other register= s can always be available when the data comes in. =20 Then you will need an address register or... if the address is only to sele= ct this slave and not to select destinations in the slave you can use a sta= te machine to recognize a match to the address. Likewise the function code= can be held in a register or matched with a state machine. Finally you wi= ll need a register for the data and the register to calculate the CRC of th= e received message which will be matched to the incoming CRC when it arrive= s. I suppose you should also have a state machine to organize the overall = operation of these circuits. =20 What is not clear to me is what happens to the data when it is received. Y= ou will need an output to indicate there is a valid output and possibly a h= and shake back saying the data was accepted.=20 Does that make sense?=20 Rick C.Article: 161209
I suspect the answer will be 'No' but never discount the obvious, so don't = be offended: While implementing the master did you write a test bench to ve= rify it? After all, the test bench for the master for any protocol is (or c= ould be) the slave, and vice versa. Even if that test bench is not synthesi= zable it gives you a starting point and reframes the query into how to conv= ert a test bench into something that can be synthesized.=20 Kevin JenningsArticle: 161210
torsdag den 14. marts 2019 kl. 15.14.49 UTC+1 skrev Swapnil Patil: > Okay First thing I haven't copied it. I wrote it myself. I know how master part works and I just explained how I designed it. > And Secondly don't put posts just to show off, if you really want help give the solution if you really that smart enough..!! if you know how the master works you also know how the slave worksArticle: 161211
On 3/13/19 3:27 AM, Anssi Saari wrote: > Tim Regeant <timbuck2@posteo.us> writes: > >> Hi all, >> >> Looking for someone who has FTP files from 1997 for the XACT >> Foundation v6.0.2 update. >> >> Web Archive has the files listed here: >> https://web.archive.org/web/19970616112705/http://www.xilinx.com/support/techsup/ftp/htm_index/sw_foundation.htm >> >> Anyone capture these files? > > I don't have those files but have you asked Xilinx? I find FPGA > companies are fairly good about providing old versions of their > software. For example, last year Lattice provided ispLEVER 5.1 when I > asked, just so we could try to recreate an old CPLD which used that > specific version. It took some time but eventually they did provide that > exact version. > Yes, I talked to Xilinx. They said they didn't keep any of the software updates, just the base versions of their software. They were very nice and helpful, but just didn't keep the files. Seems strange to me for a corporation to discard intellectual property, but I believe them. Stranger things have happened. Luckily, they put the service packs updates on their APPLINX CDs from the time. I was able to find an ISO image of one from 1997 and it has the Foundation service pack files. Now I just need to find XABEL-CPLD from 1997...Anyone have that CD? Xilinx kept no copies according to them.Article: 161212
On 3/13/19 11:50 AM, gnuarm.deletethisbit@gmail.com wrote: > On Tuesday, March 12, 2019 at 10:45:13 PM UTC-4, Tim Regeant wrote: >> Hi all, >> >> Looking for someone who has FTP files from 1997 for the XACT Foundation >> v6.0.2 update. >> >> Web Archive has the files listed here: >> https://web.archive.org/web/19970616112705/http://www.xilinx.com/support/techsup/ftp/htm_index/sw_foundation.htm >> >> Anyone capture these files? >> >> Thanks. > > I seem to recall that I had copied of XACT from around that time frame and sent them to someone. I boxed up the several boxes of software (possibly on floppy?) and shipped them out. If that person is still posting in this group perhaps he could help you? > > Rick C. > That was me Rick. I still have the CDs if anyone needs images of them. The Foundation update I was looking for was pre-M1.3 which is the earliest of the ones you sent me. M1.3 and M1.4 support the chips I use, but was looking to complete the last Foundation series updates before the "M" series. Still need to find XABEL-CPLD which was only released on CD and supported the XC7000 series of chips. Xilinx tells me they have kept no copies of this legacy software!Article: 161213
On Friday, March 15, 2019 at 10:03:12 PM UTC-4, Tim Regeant wrote: > On 3/13/19 11:50 AM, gnuarm.deletethisbit@gmail.com wrote: > > On Tuesday, March 12, 2019 at 10:45:13 PM UTC-4, Tim Regeant wrote: > >> Hi all, > >> > >> Looking for someone who has FTP files from 1997 for the XACT Foundatio= n > >> v6.0.2 update. > >> > >> Web Archive has the files listed here: > >> https://web.archive.org/web/19970616112705/http://www.xilinx.com/suppo= rt/techsup/ftp/htm_index/sw_foundation.htm > >> > >> Anyone capture these files? > >> > >> Thanks. > >=20 > > I seem to recall that I had copied of XACT from around that time frame = and sent them to someone. I boxed up the several boxes of software (possib= ly on floppy?) and shipped them out. If that person is still posting in th= is group perhaps he could help you? > >=20 > > Rick C. > >=20 >=20 > That was me Rick. I still have the CDs if anyone needs images of them.= =20 > The Foundation update I was looking for was pre-M1.3 which is the=20 > earliest of the ones you sent me. M1.3 and M1.4 support the chips I=20 > use, but was looking to complete the last Foundation series updates=20 > before the "M" series. >=20 > Still need to find XABEL-CPLD which was only released on CD and=20 > supported the XC7000 series of chips. Xilinx tells me they have kept no= =20 > copies of this legacy software! Oh, well great then. I hope you got some use of these packages. I also do= n't recall, did I send you a dongle with them? I recall there was a rather= simple anti-theft dongle that could easily be duplicated if needed. =20 Rick C.Article: 161214
Hi, I need to make a circuit which does the following thing: When it sees a red object it will send output 0 until it sees a green objec= t (like a well colored cubic toy), after it sees green it will send output = 1 until it sees red again. ( If it is hard to implement I'm ok with just ou= tput 0 when it sees red and outputs 1 when it sees green, I mean it is ok i= f the outputs not continuous but it would be great if they are continuous)= =20 I have basys3 and have to use VHDL. I think I should use TCS34725 sensor ht= tps://www.adafruit.com/product/1334 but I'm not sure I just assumed, I woul= d be really glad if someone helps Some extra questions: If it is possible I will implement it on a toy RCcar = is it possible to connect it with Bluetooth module to get inputs or how sho= uld I do it ?- I can use another board JUST FOR CONNECTIONS my main Project= should be on BASYS-3 Thanks =20Article: 161215
On Monday, March 18, 2019 at 2:28:50 PM UTC-4, utkud...@gmail.com wrote: > Hi, I need to make a circuit which does the following thing: >=20 > When it sees a red object it will send output 0 until it sees a green obj= ect (like a well colored cubic toy), after it sees green it will send outpu= t 1 until it sees red again. ( If it is hard to implement I'm ok with just = output 0 when it sees red and outputs 1 when it sees green, I mean it is ok= if the outputs not continuous but it would be great if they are continuous= )=20 >=20 > I have basys3 and have to use VHDL. I think I should use TCS34725 sensor = https://www.adafruit.com/product/1334 but I'm not sure I just assumed, I wo= uld be really glad if someone helps >=20 > Some extra questions: If it is possible I will implement it on a toy RCca= r is it possible to connect it with Bluetooth module to get inputs or how s= hould I do it ?- I can use another board JUST FOR CONNECTIONS my main Proje= ct should be on BASYS-3 >=20 > Thanks Are you familiar with finite state machines (FSM)? I think FSM will be the= best circuit for this task since you want it to remember which color it la= st saw. =20 The inputs to the FSM will need to come from a much more complex circuit th= at reads the state of the color sensor via I2C and makes a decision as to t= he color it is seeing. This will need to pick three states of the input co= lor, red, green and neither. =20 To get the color data to make these decisions will require a controller cir= cuit to read the registers in the chip. Looking at the data sheet it looks= like this is not completely straight forward but requires a sequence of op= erations to make the chip sample the light through ADCs. So you should mak= e sure you understand this process. You may want to read the library code = to see the sequence of operations implemented there while correlating that = with the data sheet. =20 So read the data sheet, look at the code and make sure you understand what = is required to get the data out of the color sensor. Once you design that = circuit you can try testing it by just driving I/O lines with the data valu= es and looking at them on the oscilloscope. If you pump the samples out se= rially, you can see it on the oscilloscope with the low order bits toggling= furiously but the higher order bits fairly stable but changing as you chan= ge colors. =20 When you think you are reading the color chip correctly, add the circuit to= weight the values and produce the two signals "red" and "green". See if y= ou can get these to work. =20 I would say you should construct a test bench and simulate it, but explaini= ng to you how to construct a model of the color chip might be more than you= can do. If you think you can do that, the test bench would be much better= than working on the actually FPGA because you can "see" any signal in the = design.=20 Rick C.Article: 161216
Most of us have implemented small processors for logic operations that don'= t need to happen at high speed. Simple CPUs can be built into an FPGA usin= g a very small footprint much like the ALU blocks. There are stack based p= rocessors that are very small, smaller than even a few kB of memory. =20 If they were easily programmable in something other than C would anyone be = interested? Or is a C compiler mandatory even for processors running very = small programs? =20 I am picturing this not terribly unlike the sequencer I used many years ago= on an I/O board for an array processor which had it's own assembler. It w= as very simple and easy to use, but very much not a high level language. T= his would have a language that was high level, just not C rather something = extensible and simple to use and potentially interactive.=20 Rick C.Article: 161217
On 19/03/2019 01:13, gnuarm.deletethisbit@gmail.com wrote: > Most of us have implemented small processors for logic operations > that don't need to happen at high speed. Simple CPUs can be built > into an FPGA using a very small footprint much like the ALU blocks. > There are stack based processors that are very small, smaller than > even a few kB of memory. > > If they were easily programmable in something other than C would > anyone be interested? Or is a C compiler mandatory even for > processors running very small programs? > > I am picturing this not terribly unlike the sequencer I used many > years ago on an I/O board for an array processor which had it's own > assembler. It was very simple and easy to use, but very much not a > high level language. This would have a language that was high level, > just not C rather something extensible and simple to use and > potentially interactive. > > Rick C. > If it is going to appeal to software developers, you need C. And it has to be reasonable, standard C, even if it is for small devices - programmers are fed up with the pains needed for special device-specific C on 8051, AVR, PIC, etc. That does not necessarily mean it has to be fast, but it should work with standard language. Having 16-bit size rather than 8-bit size makes a huge difference to how programmers feel about the device - aim for something like the msp430. You might, however, want to look at extensions for CSP-style communication between cpus - something like XMOS XC. If it is to appeal to hardware (FPGA) developers, C might not be as essential. Some other kind of high level language, perhaps centred around state machines, might work. But when I see "extensible, simple to use and potentially interactive", I fear someone is thinking of Forth. People who are very used to Forth find it a great language - but you need to understand that /nobody/ wants to learn it. Most programmers would rather work in assembler than Forth. You can argue that this attitude is irrational, and that Forth is not harder than other languages - you might be right. But that doesn't change matters.Article: 161218
On Tuesday, March 19, 2019 at 4:15:47 AM UTC-4, David Brown wrote: > On 19/03/2019 01:13, gnuarm.deletethisbit@gmail.com wrote: > > Most of us have implemented small processors for logic operations > > that don't need to happen at high speed. Simple CPUs can be built > > into an FPGA using a very small footprint much like the ALU blocks. > > There are stack based processors that are very small, smaller than > > even a few kB of memory. > >=20 > > If they were easily programmable in something other than C would > > anyone be interested? Or is a C compiler mandatory even for > > processors running very small programs? > >=20 > > I am picturing this not terribly unlike the sequencer I used many > > years ago on an I/O board for an array processor which had it's own > > assembler. It was very simple and easy to use, but very much not a > > high level language. This would have a language that was high level, > > just not C rather something extensible and simple to use and > > potentially interactive. > >=20 > > Rick C. > >=20 >=20 > If it is going to appeal to software developers, you need C. And it has > to be reasonable, standard C, even if it is for small devices - > programmers are fed up with the pains needed for special device-specific > C on 8051, AVR, PIC, etc. That does not necessarily mean it has to be > fast, but it should work with standard language. Having 16-bit size > rather than 8-bit size makes a huge difference to how programmers feel > about the device - aim for something like the msp430. >=20 > You might, however, want to look at extensions for CSP-style > communication between cpus - something like XMOS XC. >=20 > If it is to appeal to hardware (FPGA) developers, C might not be as > essential. Some other kind of high level language, perhaps centred > around state machines, might work. >=20 > But when I see "extensible, simple to use and potentially interactive", > I fear someone is thinking of Forth. People who are very used to Forth > find it a great language - but you need to understand that /nobody/ > wants to learn it. Most programmers would rather work in assembler than > Forth. You can argue that this attitude is irrational, and that Forth > is not harder than other languages - you might be right. But that > doesn't change matters. Certainly this would be like Forth, but the reality is I'm thinking of a Fo= rth like CPU because they can be designed so simply. =20 The F18A stack processor designed by Charles Moore is used in the GA144 chi= p. There are 144 of them with unusual interconnections that allow the CPU = to halt waiting for communications, saving power. The CPU is so small that= it could be included in an FPGA as what would be equivalent to a logic ele= ment. =20 In the same way that the other functional logic elements like the block RAM= s and DSP blocks are used for custom functionality which requires the desig= ner to program by whatever means is devised, these tiny CPUs would not need= a high level language like C. The code in them would be small enough to b= e considered "logic" and developed at the assembly level.=20 People have mindsets about things and I believe this is one of them. The G= A144 is not so easy to program because people want to use it for the sort o= f large programs they write for other fast CPUs. In an FPGA a very fast pr= ocessor can be part of the logic rather than an uber-controller riding herd= over the whole chip. But this would require designers to change their thi= nking of how to use CPUs. The F18A runs at 700 MIPS peak rate in a 180 nm = process. Instead of one or two in the FPGA like the ARMs in other FPGAs, t= here would be hundreds, each one running at some GHz. =20 Rick C.Article: 161219
gnuarm.deletethisbit@gmail.com wrote: > Certainly this would be like Forth, but the reality is I'm thinking of a > Forth like CPU because they can be designed so simply. > > The F18A stack processor designed by Charles Moore is used in the GA144 > chip. There are 144 of them with unusual interconnections that allow the > CPU to halt waiting for communications, saving power. The CPU is so small > that it could be included in an FPGA as what would be equivalent to a > logic element. > > In the same way that the other functional logic elements like the block > RAMs and DSP blocks are used for custom functionality which requires the > designer to program by whatever means is devised, these tiny CPUs would > not need a high level language like C. The code in them would be small > enough to be considered "logic" and developed at the assembly level. The problem this boils down to is programmability. If you have a small core, you can therefore have lots of them. But writing software for and managing dozens or hundreds of cores is troublesome. At this level, you have enough headache with the inter-core communication that you'd rather not throw a strange assembler-only core architecture into the mix. A core like this would need a simple inter-core programming model so it's easy to reason about system behaviour (example: systolic arrays) There's a certain merit in having a CPU as a building block, like a LAB, BRAM or DSP block. I'm not familiar with the literature in this space, but it's the sort of thing that turns up at the 'FPGA' conference regularly (keyword: CGRA). That merely punts the issue to now being a tools problem - the tools know how to make use of a DSP block, but how to make use of a CPU block? How to turn HDL into 'software'? Can you chain the blocks together to make wider logic? I suppose there's also a niche at the ultra-cheap end of the spectrum - for $1 gadgets with an 8051 because a 16 bit CPU would be too expensive (and a Cortex M0 would have licence fees). But if this is an ASIC then I don't think there's a whole lot more to pay to get a C-compatible processor (even in 8 bits). And it's unclear how much speed penalty you'd pay for that. How much code/data memory would you expect to have? Would that dwarf the size of your core? Finally I can see the use as a 'state machine implementation engine' for say a CPLD. But for that you need tools (taking HDL or state-transition diagrams) to allow the programmer to describe their state machine. And your competition is the regular HDL synthesiser which will just make it out of flip flops. I'm unclear how often you'd win in these circumstances. And I can't really see 'interactive' as a feature - either you have only one core, in which case you could equally hook up JTAG (or equivalent) to something larger for interactive debugging, or you have many cores, in which case I can't see how you'd interact sensibly with dozens at once. TheoArticle: 161220
On 19/03/19 00:13, gnuarm.deletethisbit@gmail.com wrote: > Most of us have implemented small processors for logic operations that don't > need to happen at high speed. Simple CPUs can be built into an FPGA using a > very small footprint much like the ALU blocks. There are stack based > processors that are very small, smaller than even a few kB of memory. > > If they were easily programmable in something other than C would anyone be > interested? Or is a C compiler mandatory even for processors running very > small programs? > > I am picturing this not terribly unlike the sequencer I used many years ago > on an I/O board for an array processor which had it's own assembler. It was > very simple and easy to use, but very much not a high level language. This > would have a language that was high level, just not C rather something > extensible and simple to use and potentially interactive. Who cares about yet another processor programmed in the same old language. It would not have a *U*SP. In fact it would be "back to the 80s" :) However, if you want to make it interesting enough to pass the elevator test, ensure it can do things that existing systems find difficult. You should have a look at how the XMOS hardware and software complement each other, so that the combination allows hard real time operation programming in multicore systems. (Hard means guaranteed-by-design latencies between successive i/o activities)Article: 161221
On 19/03/2019 09:32, gnuarm.deletethisbit@gmail.com wrote: > On Tuesday, March 19, 2019 at 4:15:47 AM UTC-4, David Brown wrote: >> On 19/03/2019 01:13, gnuarm.deletethisbit@gmail.com wrote: >>> Most of us have implemented small processors for logic >>> operations that don't need to happen at high speed. Simple CPUs >>> can be built into an FPGA using a very small footprint much like >>> the ALU blocks. There are stack based processors that are very >>> small, smaller than even a few kB of memory. >>> >>> If they were easily programmable in something other than C would >>> anyone be interested? Or is a C compiler mandatory even for >>> processors running very small programs? >>> >>> I am picturing this not terribly unlike the sequencer I used >>> many years ago on an I/O board for an array processor which had >>> it's own assembler. It was very simple and easy to use, but very >>> much not a high level language. This would have a language that >>> was high level, just not C rather something extensible and simple >>> to use and potentially interactive. >>> >>> Rick C. >>> >> >> If it is going to appeal to software developers, you need C. And >> it has to be reasonable, standard C, even if it is for small >> devices - programmers are fed up with the pains needed for special >> device-specific C on 8051, AVR, PIC, etc. That does not >> necessarily mean it has to be fast, but it should work with >> standard language. Having 16-bit size rather than 8-bit size makes >> a huge difference to how programmers feel about the device - aim >> for something like the msp430. >> >> You might, however, want to look at extensions for CSP-style >> communication between cpus - something like XMOS XC. >> >> If it is to appeal to hardware (FPGA) developers, C might not be >> as essential. Some other kind of high level language, perhaps >> centred around state machines, might work. >> >> But when I see "extensible, simple to use and potentially >> interactive", I fear someone is thinking of Forth. People who are >> very used to Forth find it a great language - but you need to >> understand that /nobody/ wants to learn it. Most programmers would >> rather work in assembler than Forth. You can argue that this >> attitude is irrational, and that Forth is not harder than other >> languages - you might be right. But that doesn't change matters. > > Certainly this would be like Forth, but the reality is I'm thinking > of a Forth like CPU because they can be designed so simply. I appreciate that. I can only tell you how /I/ would feel here, and let you use that for what you think it is worth. I don't claim to speak for all software developers, but unless other people are giving you feedback too, then this is the best you've got :-) Remember, I am not trying to argue about the pros and cons of different designs or languages, or challenge you to persuade me of anything - I'm just showing you how software developers might react to your design ideas. > > The F18A stack processor designed by Charles Moore is used in the > GA144 chip. There are 144 of them with unusual interconnections that > allow the CPU to halt waiting for communications, saving power. The > CPU is so small that it could be included in an FPGA as what would be > equivalent to a logic element. Yes, but look how popular the chip is - it is barely a blip in the landscape. There is no doubt that this is a technologically fascinating device. However, it is very difficult to program such chips - almost no one is experienced with such multi-cpu arrangements, and the design requires a completely different way of thinking from existing software design. Add to that a language that works backwards, and a syntax that looks like the cat walked across the keyboard, and you have something that has programmers running away. My experience with Forth is small and outdated, but not non-existent. I've worked with dozens of programming languages over the years - I've studied CSP, programmed in Occam, functional programming languages, lots of assemblies, a small amount of CPLD/FPGA work in various languages, and many other kinds of coding. (Most of my work for the past years has been C, C++ and Python.) I'm not afraid of learning new things. But when I looked at some of the examples for the GA144, three things struck me. One is that it was amazing how much they got on the device. Another is to wonder about the limitations you get from the this sort of architecture. (That is a big turn-off with the XMOS. It's fantastically easy to make nice software-based peripherals using hardware threads. And fantastically easy to run out of hardware threads before you've made the basic peripherals you get in a $0.50 microcontroller.) And the third thing that comes across is how totally and utterly incomprehensible the software design and the programming examples are. The GA144 is squarely in the category of technology that is cool, impressive, and useless in the real world where developers have to do a job, not play with toys. Sure, it would be possible to learn this. But there is no way I could justify the investment in time and effort that would entail. And there is no way I would want to go to a language with less safety, poorer typing, weaker tools, harder testing, more limited static checking than the development tools I can use now with C and C++. > > In the same way that the other functional logic elements like the > block RAMs and DSP blocks are used for custom functionality which > requires the designer to program by whatever means is devised, these > tiny CPUs would not need a high level language like C. The code in > them would be small enough to be considered "logic" and developed at > the assembly level. The modern way to use the DSP blocks on FPGA's is either with ready-made logic blocks, code generator tools like Matlab, or C to hardware converters. They are not configured manually at a low level. Even if when they are generated directly from VHDL or Verilog, the developer writes "x = y * z + w" with the required number of bits in each element, and the tools turn that into whatever DSP blocks are needed. The key thing you have to think about here, is who would use these tiny cpus, and why. Is there a reason for using a few of them scattered around the device, programmed in assembly (or worse, Forth) ? Why would the developer want to do that instead of just adding another software thread to the embedded ARM processor, where development is so much more familiar? Why would the hardware designer want them, instead of writing a little state machine in the language of their choice (VHDL, Verilog, System C, MyHDL, C-to-HDL compiler, whatever)? I am missing the compelling use-cases here. Yes, it is possible to make small and simple cpu units with a stack machine architecture, and fit lots of them in an FPGA. But I don't see /why/ I would want them - certainly not why they are better than alternatives, and worth the learning curve. > > People have mindsets about things and I believe this is one of them. Exactly. And you have a choice here - work with people with the mindsets they have, or give /seriously/ compelling reasons why they should invest in the time and effort needed to change those mindsets. Wishful thinking is not the answer. > The GA144 is not so easy to program because people want to use it for > the sort of large programs they write for other fast CPUs. It is not easy to program because it is not easy to program. Multi-threaded or multi-process software is harder than single-threaded code. The tools and language here for the GA144 - based on Forth - are two generations behind the times. They are totally unfamiliar to almost any current software developer. And yes, there is the question of what kind of software you would want to write. People either want to write small, dedicated software - in which case they want a language that is familiar and they want to keep the code simple. Or they want bigger projects, reusing existing code - in which case they /need/ a language that is standard. Look at the GA144 site. Apart from the immediate fact that it is pretty much a dead site, and clearly a company that has failed to take off, look at the examples. A 10 Mb software Ethernet MAC ? Who wants /that/ in software? A PS/2 keyboard controller? An MD5 hash generator running in 16 cpus? You can download a 100-line md5 function for C and run it on any processor. > In an > FPGA a very fast processor can be part of the logic rather than an > uber-controller riding herd over the whole chip. But this would > require designers to change their thinking of how to use CPUs. The > F18A runs at 700 MIPS peak rate in a 180 nm process. Instead of one > or two in the FPGA like the ARMs in other FPGAs, there would be > hundreds, each one running at some GHz. > It has long been established that lots of tiny processors running really fast are far less use than a few big processors running really fast. 700 MIPS sounds marvellous, until you realise how simple and limited each of these instructions is. At each step here, you have been entirely right about what can be done. Yes, you can make small and simple processors - so small and simple that you can have lots of them at high clock speeds. And you have been right that using these would need a change in mindset, programming language, and development practice to use them. But nowhere do I see any good reason /why/. No good use-cases. If you want to turn the software and FPGA development world on its head, you need an extraordinarily good case for it.Article: 161222
On 19/03/19 10:08, Theo Markettos wrote: > gnuarm.deletethisbit@gmail.com wrote: >> Certainly this would be like Forth, but the reality is I'm thinking of a >> Forth like CPU because they can be designed so simply. >> >> The F18A stack processor designed by Charles Moore is used in the GA144 >> chip. There are 144 of them with unusual interconnections that allow the >> CPU to halt waiting for communications, saving power. The CPU is so small >> that it could be included in an FPGA as what would be equivalent to a >> logic element. >> >> In the same way that the other functional logic elements like the block >> RAMs and DSP blocks are used for custom functionality which requires the >> designer to program by whatever means is devised, these tiny CPUs would >> not need a high level language like C. The code in them would be small >> enough to be considered "logic" and developed at the assembly level. > > The problem this boils down to is programmability. > > If you have a small core, you can therefore have lots of them. But writing > software for and managing dozens or hundreds of cores is troublesome. At > this level, you have enough headache with the inter-core communication that > you'd rather not throw a strange assembler-only core architecture into the > mix. A core like this would need a simple inter-core programming model so > it's easy to reason about system behaviour (example: systolic arrays) Yup. The hardware is easy. Programming is painful, but there are known techniques to control it... There's an existing commercially successful set of products in this domain. You get 32-core 4000MIPS processors, and the IDE guarantees the hard real-time performance. Programming uses a techniques created in the 70s, first implemented in the 80s, and which continually reappear, e.g. TI's DSP engines, Rust, Go etc. Understand XMOS's xCORE processors and xC language, see how they complement and support each other. I found the net result stunningly easy to get working first time, without having to continually read obscure errata!Article: 161223
On Tuesday, March 19, 2019 at 6:08:36 AM UTC-4, Theo Markettos wrote: > gnuarm.deletethisbit@gmail.com wrote: > > Certainly this would be like Forth, but the reality is I'm thinking of = a > > Forth like CPU because they can be designed so simply. > >=20 > > The F18A stack processor designed by Charles Moore is used in the GA144 > > chip. There are 144 of them with unusual interconnections that allow t= he > > CPU to halt waiting for communications, saving power. The CPU is so sm= all > > that it could be included in an FPGA as what would be equivalent to a > > logic element. > >=20 > > In the same way that the other functional logic elements like the block > > RAMs and DSP blocks are used for custom functionality which requires th= e > > designer to program by whatever means is devised, these tiny CPUs would > > not need a high level language like C. The code in them would be small > > enough to be considered "logic" and developed at the assembly level. >=20 > The problem this boils down to is programmability. >=20 > If you have a small core, you can therefore have lots of them. But writi= ng > software for and managing dozens or hundreds of cores is troublesome. =20 So how do they design with the many other functional elements in an FPGA? = Is it really that hard to program the various logic functions in an FPGA be= cause of the difficulty in defining their communications?=20 > At > this level, you have enough headache with the inter-core communication th= at > you'd rather not throw a strange assembler-only core architecture into th= e > mix. =20 Wow! Makes you wonder how FPGAs ever get designed at all. =20 > A core like this would need a simple inter-core programming model so > it's easy to reason about system behaviour (example: systolic arrays) "Inter-core programming model", not sure what that means.=20 I think you are overthinking this, much as people do when using large CPUs,= not to say they are overthinking for those designs. The whole point is th= at these CPUs would be used like logic blocks, not like CPUs. Small, limit= ed memory with programs written to be easy to debug and/or designed to simp= ly work by being simple. =20 I'm not sure how software people think really. I worked with one guy to tr= y to solve a problem and they were using a subroutine to do a memory access= . I suppose this was because it needed to be this specific code to get the= access to work the way it needed to. But then the guy kept looking at tho= se five lines of code for some serious time. It was pretty clear to me wha= t it was doing. Or he could have run the code or simulated it and looked t= o see what it did. Actually that would have been a valid use of JTAG to si= ngle step through those five lines a few times. But he just kept reading t= hose five lines. Wow! =20 > There's a certain merit in having a CPU as a building block, like a LAB, > BRAM or DSP block. I'm not familiar with the literature in this space, b= ut > it's the sort of thing that turns up at the 'FPGA' conference regularly > (keyword: CGRA). That merely punts the issue to now being a tools proble= m - > the tools know how to make use of a DSP block, but how to make use of a C= PU > block? How to turn HDL into 'software'? Can you chain the blocks togeth= er > to make wider logic? I don't see the difficulty. I'm not so familiar with Verilog, but in VHDL = you have sequential code. It wouldn't be hard to program a CPU using VHDL = I think. If nothing else, there should be a way to code in assembler and e= mbed the code similarly to what is done for ROM like functions in HDL.=20 > I suppose there's also a niche at the ultra-cheap end of the spectrum - f= or > $1 gadgets with an 8051 because a 16 bit CPU would be too expensive (and = a > Cortex M0 would have licence fees). =20 I believe we have officially reached the point where $1 processors are 32 b= it ARMs and you have to get below $0.50 before you consider needing 8 bit p= rocessors. Not sure what this has to do with adding CPU functional element= s to FPGAs.=20 > But if this is an ASIC then I don't > think there's a whole lot more to pay to get a C-compatible processor (ev= en > in 8 bits). And it's unclear how much speed penalty you'd pay for that. You are thinking of something totally different from using a CPU as logic. = Processors like ARMs are too large to have hundreds in an FPGA (unless it = is a really large chip). Their architectural capabilities are much more th= an what is required for this. I suppose a small 8 bit CPU could be used, b= ut why use such a tiny data path with such limited capability? The archite= ctural simplicity of a stack machine allows it to be designed to run very f= ast. With speed comes a certain flexibility to keep up with the discrete l= ogic. =20 > How much code/data memory would you expect to have? Would that dwarf the > size of your core? Small, very small. Maybe 256 words of RAM. Instructions on the F18A are o= nly 5 bits and so pack four per in the 18 bit word. The last instruction i= s only 3 bits wide expressing a subset of the 32 instructions otherwise cod= ed for. Round the word width up to 20 bits or even 32.=20 I'm not sure what happens if this actual processor is shrunk from 180 nm to= something like 20 nm. It was highly optimized for the 180 nm process it i= s built in and it may require some tweaks to work well at smaller processes= . The F18A has no external clock and different instructions time different= ly with basic logic instruction running very fast and memory accesses takin= g more time. You can think of it as an async processor.=20 > Finally I can see the use as a 'state machine implementation engine' for = say > a CPLD. But for that you need tools (taking HDL or state-transition diag= rams) > to allow the programmer to describe their state machine. And your > competition is the regular HDL synthesiser which will just make it out of > flip flops. I'm unclear how often you'd win in these circumstances. If you have logic that is well implemented sequentially (at a very high spe= ed, likely multiple GIPS) it will save a lot of room in the FPGA just as mu= ltipliers and other function blocks. Hard cores are much more efficient an= d sequential code is most efficient in a CPU type design which leverages th= e size advantage of memory over logic.=20 > And I can't really see 'interactive' as a feature - either you have only = one > core, in which case you could equally hook up JTAG (or equivalent) to > something larger for interactive debugging, or you have many cores, in wh= ich > case I can't see how you'd interact sensibly with dozens at once. If you have to use JTAG to debug something like this you are pretty much do= omed. I haven't used JTAG for anything other than programming FPGAs in dec= ades.=20 In general FPGAs are 99.9% debugged in simulation. The odd 0.1% requires p= retty special thinking anyway and I don't find JTAG to be very useful. My = best debugging tool is wetware.=20 The point of interactivity is to allow the code to be tested one definition= at a time. But then that is a Forth concept and I'm pretty sure not a fam= iliar concept with most people.=20 Rick C.Article: 161224
On Tuesday, March 19, 2019 at 2:13:38 AM UTC+2, gnuarm.del...@gmail.com wro= te: > Most of us have implemented small processors for logic operations that do= n't need to happen at high speed. Simple CPUs can be built into an FPGA us= ing a very small footprint much like the ALU blocks. There are stack based= processors that are very small, smaller than even a few kB of memory. =20 >=20 > If they were easily programmable in something other than C would anyone b= e interested? Or is a C compiler mandatory even for processors running ver= y small programs? =20 >=20 > I am picturing this not terribly unlike the sequencer I used many years a= go on an I/O board for an array processor which had it's own assembler. It= was very simple and easy to use, but very much not a high level language. = This would have a language that was high level, just not C rather somethin= g extensible and simple to use and potentially interactive.=20 >=20 > Rick C. It is clear that you have Forth in mind. It is less clear why you don't say it straight.
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