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 6/3/2016 2:29 PM, Rick C. Hodgin wrote: > On Friday, June 3, 2016 at 3:02:24 PM UTC-4, Cecil Bayona wrote: >> On 6/3/2016 1:09 PM, Rick C. Hodgin wrote: >>> On Friday, June 3, 2016 at 12:00:52 PM UTC-4, Rick C. Hodgin wrote: >>> Received: >>> http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/LatticeXP2Brevia2DevelopmentKit.aspx >>> >>> I am wanting to apply logic to this LED process, but I'm thinking there may >>> be some analog issues that I need to consider. For example, when a button >>> on the board is clicked, I assume there is some jitter time, such that if it >>> were sampled at a MHz frequency it would record jittery on/off signals for >>> a ms or two until the contact was made solid, and the same for releasing. >>> >>> As such, any logic which samples the buttons, for example, must include >>> things like identifying the first high signal, and then either sampling >>> the high/low ratio over periods of time to determine if it's still high >>> or low, and then using that value after the sampling period has expired, >>> or wait until the high signal persists solidly for something like 10ms, >>> and then consider that to be a single press event, and then wait for it >>> to go low again for something like 10ms before concluding it is actually >>> a release event. >> >> I like that board, you can implement simple CPUs in it for a low cost. >> >> This is a link to a video of FPGAs, this one is lesson 1, on lesson 2 >> they take a button and debounce it, the purpose of the project is to >> count a series of pulses on the LED based on pushing a button. >> >> -- >> Cecil - k5nwa > > Specs: > > http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735 > > In looking at the specs, it shows that all five momentary push buttons > are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not, > pin 55). > > Awesome. Should make it easier. > > What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb). I assume > output enable and write enable? But what is CS? Some kind of strobe? > Do the address and data pins go high, and write goes high, and then > it's strobed before it actually writes? Or address pins go high, and > then output goes high, and then it's strobed before data pins are > ready? Or does CS signal when the operation is complete after OE or > WE go high? > > Or are they something else entirely? :-) > > Best regards, > Rick C. Hodgin > I would not be sure that applies to any application but is what the demo does, as they do not know what you will end up doing with the I/O pins. -- Cecil - k5nwaArticle: 159001
On Friday, June 3, 2016 at 3:42:54 PM UTC-4, Cecil Bayona wrote: > On 6/3/2016 2:29 PM, Rick C. Hodgin wrote: > > Specs: > > > > http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735 > > > > In looking at the specs, it shows that all five momentary push buttons > > are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not, > > pin 55). > > > > Awesome. Should make it easier. > > > > What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb). I assume > > output enable and write enable? But what is CS? Some kind of strobe? > > Do the address and data pins go high, and write goes high, and then > > it's strobed before it actually writes? Or address pins go high, and > > then output goes high, and then it's strobed before data pins are > > ready? Or does CS signal when the operation is complete after OE or > > WE go high? > > > > Or are they something else entirely? :-) > > I would not be sure that applies to any application but is what the demo > does, as they do not know what you will end up doing with the I/O pins. I think it's chip select. It looks like there are 17 address pins. 2^17 yields 128 KB. The data reads/writes are 8-bits each, so I presume I will be reading/writing 8 bits at that byte-address. 2^17 * 8 = 1 MBit. The specs say it has 2 MBit of SRAM, so I assume CS means chip select, and could be thought of essentially as the 18th address pin? I couldn't find the video with the lessons. Do you have a link, Cecil? Best regards, Rick C. HodginArticle: 159002
On 6/3/2016 2:46 PM, Rick C. Hodgin wrote: > On Friday, June 3, 2016 at 3:42:54 PM UTC-4, Cecil Bayona wrote: >> On 6/3/2016 2:29 PM, Rick C. Hodgin wrote: >>> Specs: >>> >>> http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735 >>> >>> In looking at the specs, it shows that all five momentary push buttons >>> are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not, >>> pin 55). >>> >>> Awesome. Should make it easier. >>> >>> What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb). I assume >>> output enable and write enable? But what is CS? Some kind of strobe? >>> Do the address and data pins go high, and write goes high, and then >>> it's strobed before it actually writes? Or address pins go high, and >>> then output goes high, and then it's strobed before data pins are >>> ready? Or does CS signal when the operation is complete after OE or >>> WE go high? >>> >>> Or are they something else entirely? :-) >> >> I would not be sure that applies to any application but is what the demo >> does, as they do not know what you will end up doing with the I/O pins. > > I think it's chip select. It looks like there are 17 address pins. 2^17 > yields 128 KB. The data reads/writes are 8-bits each, so I presume I will > be reading/writing 8 bits at that byte-address. 2^17 * 8 = 1 MBit. The > specs say it has 2 MBit of SRAM, so I assume CS means chip select, and > could be thought of essentially as the 18th address pin? > > I couldn't find the video with the lessons. Do you have a link, Cecil? > > Best regards, > Rick C. Hodgin > Sorry, I forgot to add the link, but mind you the lesson is not for the Lattice board, but it's in VHDL which can be used with any board. Lesson 2 has the implementation including debouncing of buttons, and a state machine. < https://www.youtube.com/watch?v=pDE2qenDXKQ > Lesson 1 Basics < https://www.youtube.com/watch?v=uhxTgUSZvYE > Lesson 2 Button Debouncer, State Machine < https://www.youtube.com/watch?v=yoytRxOjA-A > Lesson 3 Oscilloscope, VGA output -- Cecil - k5nwaArticle: 159003
On Friday, June 3, 2016 at 6:01:44 PM UTC-4, Cecil Bayona wrote:
> On 6/3/2016 2:46 PM, Rick C. Hodgin wrote:
> > On Friday, June 3, 2016 at 3:42:54 PM UTC-4, Cecil Bayona wrote:
> >> On 6/3/2016 2:29 PM, Rick C. Hodgin wrote:
> >>> Specs:
> >>>
> >>> http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735
> >>>
> >>> In looking at the specs, it shows that all five momentary push buttons
> >>> are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not,
> >>> pin 55).
> >>>
> >>> Awesome. Should make it easier.
> >>>
> >>> What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb). I assume
> >>> output enable and write enable? But what is CS? Some kind of strobe?
> >>> Do the address and data pins go high, and write goes high, and then
> >>> it's strobed before it actually writes? Or address pins go high, and
> >>> then output goes high, and then it's strobed before data pins are
> >>> ready? Or does CS signal when the operation is complete after OE or
> >>> WE go high?
> >>>
> >>> Or are they something else entirely? :-)
> >>
> >> I would not be sure that applies to any application but is what the demo
> >> does, as they do not know what you will end up doing with the I/O pins.
> >
> > I think it's chip select. It looks like there are 17 address pins. 2^17
> > yields 128 KB. The data reads/writes are 8-bits each, so I presume I will
> > be reading/writing 8 bits at that byte-address. 2^17 * 8 = 1 MBit. The
> > specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
> > could be thought of essentially as the 18th address pin?
> >
> > I couldn't find the video with the lessons. Do you have a link, Cecil?
> >
> > Best regards,
> > Rick C. Hodgin
> >
>
> Sorry, I forgot to add the link, but mind you the lesson is not for the
> Lattice board, but it's in VHDL which can be used with any board.
>
> Lesson 2 has the implementation including debouncing of buttons, and a
> state machine.
>
> < https://www.youtube.com/watch?v=pDE2qenDXKQ > Lesson 1 Basics
> < https://www.youtube.com/watch?v=uhxTgUSZvYE > Lesson 2 Button
> Debouncer, State Machine
> < https://www.youtube.com/watch?v=yoytRxOjA-A > Lesson 3 Oscilloscope,
> VGA output
I was able to go through this tonight. This type of design is very
similar to what I plan for my Logician software:
http://blog.bastelhalde.de/?p=678
I modified it so that the input buttons also map to additional LEDs,
one each for the four inputs, to signal when they are pressed. But,
I could not figure out how to do it without going through a dual
inverter sequence. When I pulled the signal directly from the input
pin, it would synthesize without error, but it would not illuminate
the LED. I had to route it through the first inverter, then the second,
and I'm sure about why that is.
I'd like to begin working with timing and go through the stages to
get a 640x480 VGA output working with an 8x6 font. Then, get a second
Brevia2 to drive the VGA as a stand-alone hardware device communicating
graphics updates over a simple protocol, allowing for dual-ported memory
writes (one to SRAM, one to Video-RAM).
Best regards,
Rick C. Hodgin
Article: 159004Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > I think it's chip select. It looks like there are 17 address pins. 2^17 > yields 128 KB. The data reads/writes are 8-bits each, so I presume I will > be reading/writing 8 bits at that byte-address. 2^17 * 8 = 1 MBit. The > specs say it has 2 MBit of SRAM, so I assume CS means chip select, and > could be thought of essentially as the 18th address pin? CS is chip select. It's typically connected to the rest of your address decode logic: when you know you're talking to this chip and not something else, assert CS. However this is likely to be asynchronous SRAM, so the timing of CS and OE or WE set up the read or write cycle. I don't know the chip they use, but this is the datasheet for a traditional 'old fashioned' SRAM: http://6502.org/users/alexis/62256.pdf - see page 8. Since there isn't a clock going to the SRAM, you need to generate a cycle that meets the timing diagram from the chip you have. That means asserting signals in the right order and waiting the right length of time before you latch in any read data. Since the SRAM has no maximum time for an access cycle, you can just take it nice and slow by padding extra cycles in whatever clock you happen to use, and it should be fine, but you do still need to obey the right sequence. TheoArticle: 159005
Theo Markettos <theom+news@chiark.greenend.org.uk> wrote: > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: >> I think it's chip select. It looks like there are 17 address pins. 2^17 >> yields 128 KB. The data reads/writes are 8-bits each, so I presume I will >> be reading/writing 8 bits at that byte-address. 2^17 * 8 = 1 MBit. The >> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and >> could be thought of essentially as the 18th address pin? > > CS is chip select. It's typically connected to the rest of your address > decode logic: when you know you're talking to this chip and not something > else, assert CS. > > However this is likely to be asynchronous SRAM, so the timing of CS and OE or > WE set up the read or write cycle. I don't know the chip they use, but this > is the datasheet for a traditional 'old fashioned' SRAM: > http://6502.org/users/alexis/62256.pdf > - see page 8. > > Since there isn't a clock going to the SRAM, you need to generate a cycle > that meets the timing diagram from the chip you have. That means asserting > signals in the right order and waiting the right length of time before you > latch in any read data. Since the SRAM has no maximum time for an access > cycle, you can just take it nice and slow by padding extra cycles in > whatever clock you happen to use, and it should be fine, but you do still > need to obey the right sequence. I think the particular SRAM chip on the Lattice Brevia 2 board is of the true static kind. However, there are also certain pseudo-SRAM chips out there, i.e. DRAMs disguised behind an asynchronous, supposedly SRAM-compatible interface, which require CS to be deasserted every 15 us or so, in order to trigger DRAM's internal auto-refresh cycles. So don't take it for granted that CS is just an old-school chip select signal - it may be much more than that, and only digging into the datasheet of the particular chip can reveal its CS signal's true nature. MarkoArticle: 159006
On 6/4/2016 8:17 AM, Marko Zec wrote: > Theo Markettos <theom+news@chiark.greenend.org.uk> wrote: >> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: >>> I think it's chip select. It looks like there are 17 address pins. 2^17 >>> yields 128 KB. The data reads/writes are 8-bits each, so I presume I will >>> be reading/writing 8 bits at that byte-address. 2^17 * 8 = 1 MBit. The >>> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and >>> could be thought of essentially as the 18th address pin? >> >> CS is chip select. It's typically connected to the rest of your address >> decode logic: when you know you're talking to this chip and not something >> else, assert CS. >> >> However this is likely to be asynchronous SRAM, so the timing of CS and OE or >> WE set up the read or write cycle. I don't know the chip they use, but this >> is the datasheet for a traditional 'old fashioned' SRAM: >> http://6502.org/users/alexis/62256.pdf >> - see page 8. >> >> Since there isn't a clock going to the SRAM, you need to generate a cycle >> that meets the timing diagram from the chip you have. That means asserting >> signals in the right order and waiting the right length of time before you >> latch in any read data. Since the SRAM has no maximum time for an access >> cycle, you can just take it nice and slow by padding extra cycles in >> whatever clock you happen to use, and it should be fine, but you do still >> need to obey the right sequence. > > I think the particular SRAM chip on the Lattice Brevia 2 board is of the > true static kind. However, there are also certain pseudo-SRAM chips > out there, i.e. DRAMs disguised behind an asynchronous, supposedly > SRAM-compatible interface, which require CS to be deasserted every > 15 us or so, in order to trigger DRAM's internal auto-refresh cycles. > So don't take it for granted that CS is just an old-school chip select > signal - it may be much more than that, and only digging into the > datasheet of the particular chip can reveal its CS signal's true nature. > > Marko > 15 ns access time true static RAM chip. < http://www.idt.com/products/memory-logic/srams/asynchronous-srams/71v124-33v-128k-x-8-asynchronous-static-ram-center-power-ground-pinout > The board is not bad in terms of price ($43 at Mouser) for what you get, instant on, 128KB external RAM, 12 18x18 multipliers, 3 DSP Blocks, 400MHz FPGA core. Another slightly more expensive but with some extra features is the Papilio Duo for about $88 with Spartan 6 FPGA, 512 KB RAM (Optionally 2MB RAM), 8MB FLASH, that is bytes not bits, Arduino UNO with interface connectors, and a FPGA chip with 18 DSPslices. Too many toys, but not enough time. -- Cecil - k5nwaArticle: 159007
On Friday, June 3, 2016 at 10:27:07 PM UTC-4, Rick C. Hodgin wrote: > I was able to go through this tonight. This type of design is very > similar to what I plan for my Logician software: > > http://blog.bastelhalde.de/?p=678 > > I modified it so that the input buttons also map to additional LEDs, > one each for the four inputs, to signal when they are pressed. But, > I could not figure out how to do it without going through a dual > inverter sequence. When I pulled the signal directly from the input > pin, it would synthesize without error, but it would not illuminate > the LED. I had to route it through the first inverter, then the second, > and I'm sure about why that is. > > I'd like to begin working with timing and go through the stages to > get a 640x480 VGA output working with an 8x6 font. Then, get a second > Brevia2 to drive the VGA as a stand-alone hardware device communicating > graphics updates over a simple protocol, allowing for dual-ported memory > writes (one to SRAM, one to Video-RAM). I am presently hampered (to the point of significant failure) by knowing what I want to do, but not knowing the syntax to do it in Verilog (or VHDL). I'm tempted to begin working on my Logician tool so I can create its UI to operate the way I think. :-) Best regards, Rick C. HodginArticle: 159008
Currently, I have two algorithm to consider. one using FFT, one using DCT the DCT is using NEDA for FFT, I am not quite sure which one to use Do you guys have any suggestions for FFT and DCT regarding implementation ? I am now reading on NEDA and Radix. Besides, how would you guys implement DoG (Difference of Gaussian) in hardware ? Thanks !Article: 159009
Currently, I have two algorithm to consider. one using FFT, one using DCT the DCT is using NEDA for FFT, I am not quite sure which one to use Do you guys have any suggestions for FFT and DCT regarding implementation ? I am now reading on NEDA and Radix. Besides, how would you guys implement DoG (Difference of Gaussian) in hardware ? Thanks !Article: 159010
On 6/5/2016 9:34 AM, Marvin L wrote: > Currently, I have two algorithm to consider. > > one using FFT, one using DCT > the DCT is using NEDA > for FFT, I am not quite sure which one to use > > Do you guys have any suggestions for FFT and DCT regarding implementation ? > I am now reading on NEDA and Radix. > > Besides, how would you guys implement DoG (Difference of Gaussian) in hardware ? Do you have any requirements for these functions other than "they need to be implemented"? What data throughput do you require? What data representation do you need use? What type of device will it be implemented on? You are considering algorithms which is fine, but the choice of algorithm is often impacted by the requirements. -- Rick CArticle: 159011
On 5/27/2016 1:00 PM, Cecil Bayona wrote: > I a retired person with limited resources and I've always been > interested in CPU design, so now that I have time I wanted to give it a > go using FPGAs to design simple CPUs. > > I would like some advice on several topics, one being which HDL language > to learn first, although Verilog seems simpler I've read articles that > encourages beginners to start with VHDL, although it seems more wordy, I > believe it will help eliminate more dumb mistakes so I'm leaning that > way. What is your advice? > > Another is which logic families/companies make products that are > inexpensive and have good features useful in creating CPUs and DSP type > products as I also am interested in Software Defined Radios. > > I have purchase for a starter kit a Lattice Brevia2 kit as it was > inexpensive and has low power consumption, so I assume will be easier to > use in the beginning. It's a simple device with 5K LUTs which seems to > be enough for some of the simple processors that I'm interested in to > start with, CPUs such as the J1 for starters. From some time back I've > have a Xilinx Spartan 3 Started kit that I have not used, I plan to use > it later for more complex designs. > > Your opinions and advice is welcomed. I have been doing a lot of research and have come up with a plan. I have already implemented the ep8080, a high efficiency I8080 CPU a processor that I worked with for many years in my line of work, we quickly converted to the I8085 since it's hardware was more efficient, and could run at a much higher clock rate. In any case I'm ready to move on. After some deliberation and tool searching, I have decided to implement C H Tings ep32 processor as the next CPU, there are several reasons why, some are below; 1. It's a simple tested 32 bit Forth CPU, something I desire, not a work in progress. 2. It's implemented on a Brevia2 board, which I already own. 3. I have quite a bit of documentation on it, supplied by C H Ting, and it's quite good. 4. I have a Forth assembler, and compiler that generates machine code, with documentation. 5. I have the source to a resident eForth compiler for the CPU, with documentation. 6. It is written in VHDL which is the first language I want to learn. 7. I has room in the opcodes to add many new instructions. 8. It can pack multiple instructions in an instruction word to make it more efficient. 9. Large address space so I could use the external RAM to add program space. So there are a lot of advantages in the design with room for me to add instructions, and make architectural changes. I will start trying to get it working this evening after I get all my day activities all done. I've setup a virtual W7 partition with VMware Player 12, with all the development software and it all seems to work just fine, including the serial port working fine at 115K baud rate. The ep16 is next in the short future after that then the J1, and maybe the PDP11, and who knows what else. Before I move to some of these processors I need to become more familiar with VHDL as some of these CPUs such as the PDP11 with be implemented from scratch. Let the fun begin. -- Cecil - k5nwaArticle: 159012
On 6/10/2016 2:05 PM, Cecil Bayona wrote: > > The ep16 is next in the short future after that then the J1, and maybe > the PDP11, and who knows what else. Before I move to some of these > processors I need to become more familiar with VHDL as some of these > CPUs such as the PDP11 with be implemented from scratch. > > Let the fun begin. VHDL is not so hard. Just learn how to infer a register and instantiate a module and you are practically done. The rest is just logic which can be added to the register code or inferred separately. Life will be easier if you enable VHDL-2008 in your tools and use those features. If you have any questions you can ask here or maybe comp.lang.vhdl would be good too. -- Rick CArticle: 159013
On 6/10/2016 3:54 PM, rickman wrote: > On 6/10/2016 2:05 PM, Cecil Bayona wrote: >> >> The ep16 is next in the short future after that then the J1, and maybe >> the PDP11, and who knows what else. Before I move to some of these >> processors I need to become more familiar with VHDL as some of these >> CPUs such as the PDP11 with be implemented from scratch. >> >> Let the fun begin. > > VHDL is not so hard. Just learn how to infer a register and instantiate > a module and you are practically done. The rest is just logic which can > be added to the register code or inferred separately. Life will be > easier if you enable VHDL-2008 in your tools and use those features. > > If you have any questions you can ask here or maybe comp.lang.vhdl would > be good too. > I will today be starting on the ep32 CPU, later when I get back from running errands. I setup a virtual Windows 7 PC and have Lattice Diamond and other tools loaded and working. I even have the serial port on the Brevia2 board running at 115K baud rate so all is ready. I posted about it on this topic earlier today. Thanks for all the advice, and I will post in the c.l.vhdl when I have an issue with not understanding a feature of VHDL. So far looking at some books it all seems OK but a lot of details to remember. -- Cecil - k5nwaArticle: 159014
On Fri, 10 Jun 2016 16:11:09 -0500, Cecil Bayona wrote: > On 6/10/2016 3:54 PM, rickman wrote: >> On 6/10/2016 2:05 PM, Cecil Bayona wrote: >>> >>> The ep16 is next in the short future after that then the J1, and maybe >>> the PDP11, and who knows what else. Before I move to some of these >>> processors I need to become more familiar with VHDL as some of these >>> CPUs such as the PDP11 with be implemented from scratch. >>> >>> Let the fun begin. >> >> VHDL is not so hard. Just learn how to infer a register and >> instantiate a module and you are practically done. The rest is just >> logic which can be added to the register code or inferred separately. >> Life will be easier if you enable VHDL-2008 in your tools and use those >> features. >> >> If you have any questions you can ask here or maybe comp.lang.vhdl >> would be good too. >> > I will today be starting on the ep32 CPU, later when I get back from > running errands. > > I setup a virtual Windows 7 PC and have Lattice Diamond and other tools > loaded and working. I even have the serial port on the Brevia2 board > running at 115K baud rate so all is ready. I posted about it on this > topic earlier today. > > Thanks for all the advice, and I will post in the c.l.vhdl when I have > an issue with not understanding a feature of VHDL. So far looking at > some books it all seems OK but a lot of details to remember. I don't even try to remember all the details of C++ (which is my main computer language). I just remember what's possible, and enough terms that I can use a book with a good index, or a site with a good search engine, and look up what I need to know. Then I use it, then I forget it again. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!Article: 159015
On 5/13/2011 7:34 AM, wzab wrote: > Hi, > > I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html > I'd like to use it to implement simple non-time critical control and > debugging layer > in my FPGA based DSP system. > However to accomplish it I need to add possibility of interactive work > via console > connected either by UART or by JTAG. > Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz > with possibility to interactively define new words and execute them? > -- > TIA & Regards, > WZab > I have not done it, I'm just starting using FPGA, however the J1 is on my short list of processors to implement. I'm in the process of learning VHDL so I will be doing my own take using VHDL instead of Verilog. Once up and running then my plans is to do upgrades to it. Sorry if this doesn't help you, but I'm heading in that general direction. Currently my plans are to implement the ep32 and the ep16 first since I have decent documentation and development software for those two CPUs. -- Cecil - k5nwaArticle: 159016
On 6/10/2016 9:36 PM, Cecil Bayona wrote: > On 5/13/2011 7:34 AM, wzab wrote: >> Hi, >> >> I'm very impressed with a J1 forth processor: >> http://excamera.com/sphinx/fpga-j1.html >> I'd like to use it to implement simple non-time critical control and >> debugging layer >> in my FPGA based DSP system. >> However to accomplish it I need to add possibility of interactive work >> via console >> connected either by UART or by JTAG. >> Has anybody tried to extend the J1 published in >> http://excamera.com/files/j1demo.tar.gz >> with possibility to interactively define new words and execute them? >> -- >> TIA & Regards, >> WZab >> > I have not done it, I'm just starting using FPGA, however the J1 is on > my short list of processors to implement. I'm in the process of learning > VHDL so I will be doing my own take using VHDL instead of Verilog. Once > up and running then my plans is to do upgrades to it. > > Sorry if this doesn't help you, but I'm heading in that general > direction. Currently my plans are to implement the ep32 and the ep16 > first since I have decent documentation and development software for > those two CPUs. Seems you replied to a rather old post. I expect wzab's project is quite done at this point. I'm not sure what he meant by "interactively define new words and execute them". Someone else, maybe in the Forth group, wanted to do something like that where the basic instruction set could be extended by compiling Forth. I have worked with microcoded machines and the only way I can think that would be done would be through a special set of primitives that were specific to the CPU rather than typical Forth primitives. You can think of Forth as the instruction set for a stack machine. Inventing new primitives would essentially mean writing new microcode rather than using the existing primitives. I think that would be rather a lot of Forth to generate that new microcode from Forth primitives. I suppose it is doable though. Maybe I just haven't been able to simplify the problem enough to see the solution. -- Rick CArticle: 159017
On 6/10/2016 10:06 PM, rickman wrote: > On 6/10/2016 9:36 PM, Cecil Bayona wrote: >> On 5/13/2011 7:34 AM, wzab wrote: >>> Hi, >>> >>> I'm very impressed with a J1 forth processor: >>> http://excamera.com/sphinx/fpga-j1.html >>> I'd like to use it to implement simple non-time critical control and >>> debugging layer >>> in my FPGA based DSP system. >>> However to accomplish it I need to add possibility of interactive work >>> via console >>> connected either by UART or by JTAG. >>> Has anybody tried to extend the J1 published in >>> http://excamera.com/files/j1demo.tar.gz >>> with possibility to interactively define new words and execute them? >>> -- >>> TIA & Regards, >>> WZab >>> >> I have not done it, I'm just starting using FPGA, however the J1 is on >> my short list of processors to implement. I'm in the process of learning >> VHDL so I will be doing my own take using VHDL instead of Verilog. Once >> up and running then my plans is to do upgrades to it. >> >> Sorry if this doesn't help you, but I'm heading in that general >> direction. Currently my plans are to implement the ep32 and the ep16 >> first since I have decent documentation and development software for >> those two CPUs. > > Seems you replied to a rather old post. I expect wzab's project is > quite done at this point. > > I'm not sure what he meant by "interactively define new words and > execute them". Someone else, maybe in the Forth group, wanted to do > something like that where the basic instruction set could be extended by > compiling Forth. > > I have worked with microcoded machines and the only way I can think that > would be done would be through a special set of primitives that were > specific to the CPU rather than typical Forth primitives. You can think > of Forth as the instruction set for a stack machine. Inventing new > primitives would essentially mean writing new microcode rather than > using the existing primitives. I think that would be rather a lot of > Forth to generate that new microcode from Forth primitives. I suppose > it is doable though. Maybe I just haven't been able to simplify the > problem enough to see the solution. Just to clarify, a microcoded machine has fields or individual bits which control... well, control points. The CPU has many register enables, multiplexers and other functions that need to controlled. The signals that do all this are "control points". A microcoded machine generates those control points either through a 1 to 1 mapping of microcode bits to control bits (a very wide instruction word) or control points that are mutually exclusive can be encoded into a field which is decoded by logic to generate the control points saving microcode memory. Even if the encoded control points aren't mutually exclusive by the hardware design, they will be if encoded. The primitives for such a microcoded machine would be the control points. In Forth a word could be defined for each one and one for each of the possible selections in an encoded field (hopefully checking if any of the other mutually exclusive words had been used already in this instruction). Not entirely unlike assembly language done in Forth each field could be entered building up the instruction until a finishing word uses that instruction and inserts it into the microcode memory. Maybe this is not so much more complex than standard assembly language, certainly there aren't all the addressing modes, etc. But I would have a hard time figuring out how to map existing Forth primitives to microcode to define new instructions/new Forth primitives. Simply inserting the same sequence of microcode words as exist in the definitions for the Forth primitives would not be terribly useful since there likely would be very little or even no overhead in using Forth primitives. Being able to define new instructions that do new or different things would not be easy to specify in standard Forth primitives. This would need to be done using microcode primitives. -- Rick CArticle: 159018
Rickman, > I'm not sure what he meant by "interactively define new words and > execute them". Someone else, maybe in the Forth group, wanted to do > something like that where the basic instruction set could be extended by > compiling Forth. You are overthinking things. What he meant was that he wanted a native J1 Forth system instead of the cross Forth system most projects were using. So you would connect a terminal to the FPGA board and would see an "Ok" prompt and then you could define new words by typing ": name ...." on the terminal. You would also be able to try simple expressions like "3 4 + ." and see immediately what they do. With cross development you type in your program in some editor on your PC, run the compiler and get a bunch of bits to be loaded into the FPGA board. You turn on the FPGA board and see if it worked or not. If not, you got back to the editor on your PC and start the whole cycle again. This works, but it is not how Forth was meant to be used. -- JecelArticle: 159019
On 6/13/2016 12:52 PM, Jecel wrote: > Rickman, > >> I'm not sure what he meant by "interactively define new words and >> execute them". Someone else, maybe in the Forth group, wanted to do >> something like that where the basic instruction set could be extended by >> compiling Forth. > > You are overthinking things. What he meant was that he wanted a native J1 > Forth system instead of the cross Forth system most projects were using. > So you would connect a terminal to the FPGA board and would see an "Ok" > prompt and then you could define new words by typing ": name ...." on > the terminal. You would also be able to try simple expressions like > "3 4 + ." and see immediately what they do. > > With cross development you type in your program in some editor on your > PC, run the compiler and get a bunch of bits to be loaded into the FPGA > board. You turn on the FPGA board and see if it worked or not. If not, > you got back to the editor on your PC and start the whole cycle again. > This works, but it is not how Forth was meant to be used. A target hosted Forth has it's advantages, but I still type my source into an editor on the PC and compile by downloading to the target rather than loading into a Forth crosscompiler which downloads it for me. Not sure there is a huge advantage either way. They seem pretty similar to me including the need to hit the reset button when I screw up bad enough. You make it sound like the edit, compile, test loop is somehow much less useful when using a PC. I got rid of my ADM-3A a long time ago. -- Rick CArticle: 159020
On Monday, June 13, 2016 at 4:21:21 PM UTC-3, Rickman wrote: > You make it sound like the edit, compile, test loop is somehow much less > useful when using a PC. I got rid of my ADM-3A a long time ago. Compare developing a game in Basic on a Commodore 64 with creating the same game on a PC, using a Basic-to-6502 compiler and downloading it to the C64 to see if it works. Development is faster in the first option while the resulting game will be faster in the second option. What I am saying is that I don't like edit/compile/test loops but prefer interpreted systems (or those that do a good job of pretending to be interpreted - see Smalltalks with JIT compilation). You are free to prefer compiled systems (most people do) but wzab seems to have the same taste as me and was asking for an option to develop interactively on the J1 processor itself. -- JecelArticle: 159021
On 6/14/2016 3:52 PM, Jecel wrote: > On Monday, June 13, 2016 at 4:21:21 PM UTC-3, Rickman wrote: >> You make it sound like the edit, compile, test loop is somehow much less >> useful when using a PC. I got rid of my ADM-3A a long time ago. > > Compare developing a game in Basic on a Commodore 64 with creating the > same game on a PC, using a Basic-to-6502 compiler and downloading it to > the C64 to see if it works. Development is faster in the first option > while the resulting game will be faster in the second option. That is not at all clear to me. Your example seems to be compiling native on one type of PC vs. cross compiling on another and transferring the executable. I don't expect to have anything like mass storage on the target system, so the two options I have are using the PC for program storage or using the PC to cross compile. I can download at nearly 1 Mbps today using the ubiquitous USB serial ports. I don't perceive any difference in time of loading an executable vs. loading the program source. Compile times are very fast as well. > What I am saying is that I don't like edit/compile/test loops but > prefer interpreted systems (or those that do a good job of pretending > to be interpreted - see Smalltalks with JIT compilation). You still have the loop, you think it is faster the way you are describing, but I use the same command line for testing. I just use the PC as an editor. > You are free to prefer compiled systems (most people do) but wzab seems > to have the same taste as me and was asking for an option to develop > interactively on the J1 processor itself. That's fine if the J1 has facilities for the full development process. I can't remember the last time I used a target that was even close to being able to support a full development system other than the Raspberry Pi. What sort of J1 hardware are you looking at? -- Rick CArticle: 159022
On Tuesday, June 14, 2016 at 5:16:08 PM UTC-3, Rickman wrote: > > What I am saying is that I don't like edit/compile/test loops but > > prefer interpreted systems (or those that do a good job of pretending > > to be interpreted - see Smalltalks with JIT compilation). > > You still have the loop, you think it is faster the way you are > describing, but I use the same command line for testing. I just use the > PC as an editor. "the same command line" might be the key to our differences. In the native C64 Basic command line I can type something like PRINT (MADD/4)+1 and see the result. In a cross compiling Basic I can't do that. > > You are free to prefer compiled systems (most people do) but wzab seems > > to have the same taste as me and was asking for an option to develop > > interactively on the J1 processor itself. > > That's fine if the J1 has facilities for the full development process. > I can't remember the last time I used a target that was even close to > being able to support a full development system other than the Raspberry > Pi. What sort of J1 hardware are you looking at? The J1 can't address much memory, so a native Forth is possible but would be a tight fit. You mentioned a lack of mass storage on the target device, but these days you can easily have 64Kb of Flash or more. In any case, my own SiliconSqueak is way larger than the J1 and is meant for boards with more resources, though not necessarily as large as a Raspberry Pi. -- JecelArticle: 159023
On 6/15/2016 5:43 PM, Jecel wrote: > On Tuesday, June 14, 2016 at 5:16:08 PM UTC-3, Rickman wrote: >>> What I am saying is that I don't like edit/compile/test loops but >>> prefer interpreted systems (or those that do a good job of pretending >>> to be interpreted - see Smalltalks with JIT compilation). >> >> You still have the loop, you think it is faster the way you are >> describing, but I use the same command line for testing. I just use the >> PC as an editor. > > "the same command line" might be the key to our differences. In the > native C64 Basic command line I can type something like > > PRINT (MADD/4)+1 > > and see the result. In a cross compiling Basic I can't do that. There's the problem. I'm using Forth. I didn't know we were talking about BASIC. >>> You are free to prefer compiled systems (most people do) but wzab seems >>> to have the same taste as me and was asking for an option to develop >>> interactively on the J1 processor itself. >> >> That's fine if the J1 has facilities for the full development process. >> I can't remember the last time I used a target that was even close to >> being able to support a full development system other than the Raspberry >> Pi. What sort of J1 hardware are you looking at? > > The J1 can't address much memory, so a native Forth is possible but would > be a tight fit. I don't recall the limitation, but I would expect it to be on the order of many KB. Mecrisp is not so large and in fact, I'm pretty sure it has been ported to the J1. I seem to recall this was done using an open source package (the only one I've ever heard of) that compiles to a bit stream. In a fit of enthusiasm I believe Matthias Koch ported his Forth to this target making the entire effort open source. I can't recall for sure, but I'm pretty sure the hardware is also open source. > You mentioned a lack of mass storage on the target device, but these days > you can easily have 64Kb of Flash or more. 64 kB of on target flash is not of much value for storing source. You have virtually no tools for printing, copying, backup, etc. I use a PC for all that. > In any case, my own SiliconSqueak is way larger than the J1 and is meant > for boards with more resources, though not necessarily as large as a > Raspberry Pi. You mean an FPGA board? The rPi has a higher end ARM processor. -- Rick CArticle: 159024
On Wednesday, June 15, 2016 at 7:14:06 PM UTC-3, Rickman wrote: > On 6/15/2016 5:43 PM, Jecel wrote: > > "the same command line" might be the key to our differences. In the > > native C64 Basic command line I can type something like > > > > PRINT (MADD/4)+1 > > > > and see the result. In a cross compiling Basic I can't do that. > > There's the problem. I'm using Forth. I didn't know we were talking > about BASIC. :-) So we type MADD @ 4 / 1 + . instead. The point is that I don't have to first put that expression in a colon definition, compile it, and then send it to the target board to see the result. > > The J1 can't address much memory, so a native Forth is possible but would > > be a tight fit. > > I don't recall the limitation, but I would expect it to be on the order > of many KB. Let me check: http://excamera.com/files/j1.pdf "All target addresses - for call, jump and conditional branch - are 13-bit. This limits code size to 8K words, or 16K bytes." Data uses 15 bit byte addresses, but the top half of the memory map is reserved for I/O. So was have 16KB in all to play with. > Mecrisp is not so large and in fact, I'm pretty sure it has > been ported to the J1. I seem to recall this was done using an open > source package (the only one I've ever heard of) that compiles to a bit > stream. In a fit of enthusiasm I believe Matthias Koch ported his Forth > to this target making the entire effort open source. I can't recall for > sure, but I'm pretty sure the hardware is also open source. Ok, so the answer to the original question is "yes"? Good. I've had some nice machines (Mac, Sun Utra 5+, XO-1 from One Laptop Per Child) with OpenFirmware (OpenBoot, as Sun called it) and it is a nice token threaded Forth that can be used interactively. Not only is token threading really compact, but it can also be used on Harvard architecture chips like the Atmel AVR8. > > You mentioned a lack of mass storage on the target device, but these days > > you can easily have 64Kb of Flash or more. > > 64 kB of on target flash is not of much value for storing source. You > have virtually no tools for printing, copying, backup, etc. I use a PC > for all that. Normally, I would agree. But for Forth or Basic (as in BasicStamp boards) it might be enough. Most early microcomputers had 80KB floppy disks. > > In any case, my own SiliconSqueak is way larger than the J1 and is meant > > for boards with more resources, though not necessarily as large as a > > Raspberry Pi. > > You mean an FPGA board? The rPi has a higher end ARM processor. The R-Pi also has SDRAM, HDMI output, USBs and Ethernet which is also the case for some FPGA boards. And those with chips like Zynq have FPGAs and ARMs. What I was saying was that I am also interested in FPGA boards with not as much memory and with poorer I/O (VGA and PS/2, for example) than the Pi. -- Jecel
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