In article <b8411641-e13d-46b7-adaf-52690a50b84dn@googlegroups.com>,
>How 'bout you take a look at it and decide for yourself?

How to snip a lines that are not relevant so that we can understand
what you're talking about?

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Thursday, December 8, 2022 at 6:28:32 AM UTC-5, none albert wrote:
> In article <b8411641-e13d-46b7...@googlegroups.com>,
> >How 'bout you take a look at it and decide for yourself?
> How to snip a lines that are not relevant so that we can understand
> what you're talking about?
>
> Groetjes Albert
> --
> "in our communism country Viet Nam, people are forced to be
> alive and in the western country like US, people are free to
> die from Covid 19 lol" duc ha
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Relax, it's nothing that concerns you.

On Thursday, December 8, 2022 at 5:36:59 AM UTC-4, Myron Plichota wrote:
> On Thursday, December 8, 2022 at 3:58:43 AM UTC-5, gnuarm.del...@gmail.com wrote:
> > On Thursday, December 8, 2022 at 4:16:38 AM UTC-4, Myron Plichota wrote:
> > > On Thursday, December 8, 2022 at 3:02:51 AM UTC-5, gnuarm.del...@gmail.com wrote:
> > > > On Thursday, December 8, 2022 at 2:55:02 AM UTC-4, Myron Plichota wrote:
> > > > > On Tuesday, December 6, 2022 at 10:51:21 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > > > > > On Tuesday, December 6, 2022 at 7:47:33 AM UTC-4, Myron Plichota wrote:
> > > > > > > On Tuesday, December 6, 2022 at 2:43:09 AM UTC-5, gnuarm.del....@gmail.com wrote:
> > > > > > > > On Monday, December 5, 2022 at 10:04:47 PM UTC-5, Myron Plichota wrote:
> > > > > > > > > On Monday, December 5, 2022 at 12:53:15 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > > > > > > > > > On Monday, December 5, 2022 at 3:38:14 AM UTC-5, Myron Plichota wrote:
> > > > > > > > > > > On Sunday, December 4, 2022 at 10:04:16 AM UTC-5, jpit...@gmail.com wrote:
> > > > > > > > > > > > On Sunday, 4 December 2022 at 11:59:54 UTC, Myron Plichota wrote:
> > > > > > > > > > > > > On Sunday, December 4, 2022 at 4:26:27 AM UTC-5, jpit...@gmail.com wrote:
> > > > > > > > > > > > > > On Saturday, 3 December 2022 at 16:00:41 UTC, James Brakefield wrote:
> > > > > > > > > > > > > > > On Saturday, December 3, 2022 at 5:32:00 AM UTC-6, jpit...@gmail.com wrote:
> > > > > > > > > > > > > > > > On Wednesday, 30 November 2022 at 12:55:49 UTC, Myron Plichota wrote:
> > > > > > > > > > > > > > > > > The hardware is defined in Verilog. The *structured* assembler is written in Python3. Apps source code plays ball with the Python3 foundation.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > e.g. apps/color_toy.py:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > include('FPGAburn/appload.py') # must be on the first line
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > # play with LD0 color
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > ja(fwd('init'))
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('app_msg'); ascii('\r\npress BTN0 to reset')
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > # color intensities
> > > > > > > > > > > > > > > > > lbl('red'); data([0])
> > > > > > > > > > > > > > > > > lbl('green'); data([0])
> > > > > > > > > > > > > > > > > lbl('blue'); data([0])
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > # commands
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('ir') # char -> # increment red
> > > > > > > > > > > > > > > > > drop(); lld(red); inc(); lst(red); ret()
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('dr') # char -> # decrement red
> > > > > > > > > > > > > > > > > drop(); lld(red); dec(); lst(red); ret()
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('ig') # char -> # increment green
> > > > > > > > > > > > > > > > > drop(); lld(green); inc(); lst(green); ret()
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('dg') # char -> # decrement green
> > > > > > > > > > > > > > > > > drop(); lld(green); dec(); lst(green); ret()
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('ib') # char -> # increment blue
> > > > > > > > > > > > > > > > > drop(); lld(blue); inc(); lst(blue); ret()
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('db') # char -> # decrement blue
> > > > > > > > > > > > > > > > > drop(); lld(blue); dec(); lst(blue); ret()
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('command') # -> # execute a recognized command
> > > > > > > > > > > > > > > > > lld(arx_rdy)
> > > > > > > > > > > > > > > > > _if()
> > > > > > > > > > > > > > > > > lld(uart); dup(); cp(tx) # -> char # echo
> > > > > > > > > > > > > > > > > dup(); lbxor(ord('R')); jz(ir)
> > > > > > > > > > > > > > > > > dup(); lbxor(ord('r')); jz(dr)
> > > > > > > > > > > > > > > > > dup(); lbxor(ord('G')); jz(ig)
> > > > > > > > > > > > > > > > > dup(); lbxor(ord('g')); jz(dg)
> > > > > > > > > > > > > > > > > dup(); lbxor(ord('B')); jz(ib)
> > > > > > > > > > > > > > > > > dup(); lbxor(ord('b')); jz(db)
> > > > > > > > > > > > > > > > > drop() # none of the above
> > > > > > > > > > > > > > > > > _then()
> > > > > > > > > > > > > > > > > ret()
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('init')
> > > > > > > > > > > > > > > > > lit(app_msg); cp(tx_ascii)
> > > > > > > > > > > > > > > > > _begin()
> > > > > > > > > > > > > > > > > cp(command)
> > > > > > > > > > > > > > > > > lld(red); lst(pwm1)
> > > > > > > > > > > > > > > > > lld(green); lst(pwm2)
> > > > > > > > > > > > > > > > > lld(blue); lst(pwm3)
> > > > > > > > > > > > > > > > > _again()
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > lbl('app_end') # must be on the last line
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > BugsBoard_Primer.pdf is at https://drive.google.com/file/d/14iPt_j_lmINSs4cte3_MneA6D4UCBjZi/view?usp=sharing
> > > > > > > > > > > > > > > > > A link to Bugs18bis.zip is in the downloads section.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Cheers - Myron Plichota
> > > > > > > > > > > > > > > > The number of people who own such a board is probably rather small.
> > > > > > > > > > > > > > > > And cost/availability might be an issue for many who want to give it a go.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I wonder if the NANDLAND Board / Lattice based could be a target for your software.
> > > > > > > > > > > > > > > > This would probably cover as well the related board from Lattice.
> > > > > > > > > > > > > > > > https://nandland.com/the-go-board/ has a lot of related documentation to get started.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Nandland board $65,
> > > > > > > > > > > > > > > > https://digilent.com/reference/programmable-logic/cmod-s7/start at $99 and not available at the moment
> > > > > > > > > > > > > > > FPGA board prices have gone way op over the last few years.
> > > > > > > > > > > > > > > If you are a FPGA beginner and a student and want to avoid using a plug board,
> > > > > > > > > > > > > > > the Terasic DE10-Lite and the Realdigital BooleanBoard give you the most for your money.
> > > > > > > > > > > > > > > If user IO (buttons, switches and 7-segment display) is not an issue, the Tang Nano 9K deserves a look.
> > > > > > > > > > > > > > I had been looking at these low-cost boards at Pimoroni - but out of stock as expected.
> > > > > > > > > > > > > > https://shop.pimoroni.com/search?q=fpga%20board
> > > > > > > > > > > > > > But I still own many different versions from the past including some of those from Trenz-Electronics that I could use
> > > > > > > > > > > > > > https://shop.trenz-electronic.de/en/Products/Trenz-Electronic/TE0890-Spartan-7/ good for breadboards
> > > > > > > > > > > > > > The last time I switched one on, was
> > > > > > > > > > > > > > to verify the CDP1802 that Steve Teal did
> > > > > > > > > > > > > > https://www.amazon.co.uk/FIG-Forth-Manual-Documentation-Test-1802-ebook/dp/B01N42VLJE/ref=sr_1_19?qid=1670145231&refinements=p_27%3AJuergen+Pintaske&s=books&sr=1-19
> > > > > > > > > > > > > > and this got me to redo the CDP1802 book BMP802 and publish it on amazon as well
> > > > > > > > > > > > > > https://www.amazon.co.uk/DESIGN-IDEAS-BOOK-CDP1802-Microprocesor-ebook/dp/B09GWCVHGG/ref=sr_1_10?qid=1670145353&refinements=p_27%3AJuergen+Pintaske&s=books&sr=1-10
> > > > > > > > > > > > > > All for the fun of it.
> > > > > > > > > > > > > https://shop.trenz-electronic.de/en/Products/Trenz-Electronic/TE0890-Spartan-7/
> > > > > > > > > > > > > This has definite transplant potential. It uses the same XC7S25 FPGA.
> > > > > > > > > > > > > But:
> > > > > > > > > > > > > 1) I don't see an on-board USB/UART connector. But I see FTDI on the silk screen, which suggests a workaround.
> > > > > > > > > > > > > 2) Through-hole pin pitch is not consistently on a 0.1"x0.1" grid, and this is bad for a hobby board.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The published BugsBoard design is far from holy, e.g. 3 PWM channels are dedicated to drive the on-board RGB LED for fun.
> > > > > > > > > > > > > I'd be delighted to hear about succesful mutations on other FPGA-based boards.
> > > > > > > > > > > > There are so many versions on the website, this one might fit better for you
> > > > > > > > > > > > https://shop.trenz-electronic.de/en/Products/Programmable-Logic/Gowin-LittleBee/
> > > > > > > > > > > >
> > > > > > > > > > > > And regarding 0.1" pitch: I have used this solution in the past:
> > > > > > > > > > > > male headers soldered into the board
> > > > > > > > > > > > female header stuck onlo them
> > > > > > > > > > > > short wires soldered to female header
> > > > > > > > > > > > the other end of the wire soldered onto male header and this stuck into the breadboard.
> > > > > > > > > > > > And if this is too wide for a normal breadboard - one breadboard on each side and a lot of space for extensions ...
> > > > > > > > > > > A quick review of the FPGA datasheet shows problems:
> > > > > > > > > > > 1) block RAM lacks separate read and write clocks in single-port mode
> > > > > > > > > > That would be called "semi-dual port" mode.
> > > > > > > > > > > 2) there is a maximum of 26Kx18-bits block RAM available
> > > > > > > > > > Every part has limitations. Why is 26 blocks of 2k x 18 BRAM a serious limitation? I'm planning to use this part in a design I'm working on.
> > > > > > > > > > > I do not recommend that board.
> > > > > > > > > > For what?
> > > > > > > > > >
> > > > > > > > > > If you look at the schematics for this board, it will show the particular FTDI chip used. That will provide a lot of information about how to use it. It has been a couple of years, but I seem to recall that chip can provide both JTAG programming, and a serial port.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > > Rick C.
> > > > > > > > > >
> > > > > > > > > > - Get 1,000 miles of free Supercharging
> > > > > > > > > > - Tesla referral code - https://ts.la/richard11209
> > > > > > > > > Popping the stack:
> > > > > > > > > 1) Q: do not recommend for what? A: a BugsBoard transplant
> > > > > > > > > 2) Q: RAM limitation? A: depends on how much (or little) on-chip code and data you have use for
> > > > > > > > > 3) semi dual port mode: I noticed that, and the block diagram does not suggest to me that ram1c.v would successfully compile.
> > > > > > > > Not sure what you don't like about that file. I don't have time right now to dig into it. Is ram1c.v a file in the project you are talking about, or something from Gowin?
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Rick C.
> > > > > > > >
> > > > > > > > +-- Get 1,000 miles of free Supercharging
> > > > > > > > +-- Tesla referral code - https://ts.la/richard11209
> > > > > > > Please take the time to comprehend ram1c.v in the BugsBoard.zip distro. Perchance it will serve you well. BTW, I never heard about Gowin before this discussion was started.
> > > > > > I'm sure there are many things I can spend my time studying. Is there some particular lesson in this file I should be aware of?
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Rick C.
> > > > > >
> > > > > > -- Get 1,000 miles of free Supercharging
> > > > > > -- Tesla referral code - https://ts.la/richard11209
> > > > > How 'bout you take a look at it and decide for yourself?
> > > > Sure, as soon as I find time to look at a random piece of code someone has not said anything about.
> > > >
> > > > Thanks...
> > > >
> > > > --
> > > >
> > > > Rick C.
> > > >
> > > > -+ Get 1,000 miles of free Supercharging
> > > > -+ Tesla referral code - https://ts.la/richard11209
> > > ram1c.v is in the Verilog directory within Bugs18bis.zip. Perhaps you will be the first one to say something about it.
> > So where do I find this zip file?
> >
> > --
> >
> > Rick C.
> >
> > +- Get 1,000 miles of free Supercharging
> > +- Tesla referral code - https://ts.la/richard11209
> Bugs18bis.zip is at https://drive.google.com/file/d/1cWZmDik5PlWaEd-srekTiF51chDR8b7_/view?usp=share_link
> BTW this link is also in the downloads section of BugsBoard_Primer.pdf at https://drive.google.com/file/d/14iPt_j_lmINSs4cte3_MneA6D4UCBjZi/view?usp=sharing
> I tried to convey this info in my kickoff post, but I'm a geek, not a salesman.

On Thursday, December 8, 2022 at 10:13:04 AM UTC-5, gnuarm.del...@gmail.com wrote:
> On Thursday, December 8, 2022 at 5:36:59 AM UTC-4, Myron Plichota wrote:
> > Bugs18bis.zip is at https://drive.google.com/file/d/1cWZmDik5PlWaEd-srekTiF51chDR8b7_/view?usp=share_link
> > BTW this link is also in the downloads section of BugsBoard_Primer.pdf at https://drive.google.com/file/d/14iPt_j_lmINSs4cte3_MneA6D4UCBjZi/view?usp=sharing
> > I tried to convey this info in my kickoff post, but I'm a geek, not a salesman.
> I looked at the file. You wish to use opposite edges of the clock for read and write.
>
> Before I make any comments, I want to ask, why was it necessary for me to read the file in order for you to ask a question?

For the same reason that I follow links posted here before I add my 2 cents. Otherwise, I wouldn't know what questions to ask, or have a factual basis for my opinion. Was it such an ordeal viewing 25 lines of Verilog?

On Friday, December 9, 2022 at 6:14:50 AM UTC-4, Myron Plichota wrote:
> On Thursday, December 8, 2022 at 10:13:04 AM UTC-5, gnuarm.del...@gmail.com wrote:
> > On Thursday, December 8, 2022 at 5:36:59 AM UTC-4, Myron Plichota wrote:
> > > Bugs18bis.zip is at https://drive.google.com/file/d/1cWZmDik5PlWaEd-srekTiF51chDR8b7_/view?usp=share_link
> > > BTW this link is also in the downloads section of BugsBoard_Primer.pdf at https://drive.google.com/file/d/14iPt_j_lmINSs4cte3_MneA6D4UCBjZi/view?usp=sharing
> > > I tried to convey this info in my kickoff post, but I'm a geek, not a salesman.
> > I looked at the file. You wish to use opposite edges of the clock for read and write.
> >
> > Before I make any comments, I want to ask, why was it necessary for me to read the file in order for you to ask a question?
> For the same reason that I follow links posted here before I add my 2 cents. Otherwise, I wouldn't know what questions to ask, or have a factual basis for my opinion. Was it such an ordeal viewing 25 lines of Verilog?

It was pointless, just as this entire discussion. You seem to enjoy distracting from the conversation, rather than promoting a conversation. You posted that you didn't like a board, without explaining why. When asked, rather than saying, you need to clock on opposite edges of the clock, you travel down a rabbit hole of obstruction.

In the end, I found that your complaint is baseless. You don't seem to understand block RAMs, or at least don't understand the Gowin BRAMs. Did you try synthesizing this file? Again, no information from you on this.

You didn't post your 2 cents. You posted noise.

In response to your file, what you would use is Semi-Dual Port Mode.

Now, learn how to have a discussion rather than being a bit of a jerk. Oh, and you are welcome for the advice on how to use the Gowin BRAM.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

On Friday, 9 December 2022 at 11:50:24 UTC, gnuarm.del...@gmail.com wrote:
> On Friday, December 9, 2022 at 6:14:50 AM UTC-4, Myron Plichota wrote:
> > On Thursday, December 8, 2022 at 10:13:04 AM UTC-5, gnuarm.del...@gmail..com wrote:
> > > On Thursday, December 8, 2022 at 5:36:59 AM UTC-4, Myron Plichota wrote:
> > > > Bugs18bis.zip is at https://drive.google.com/file/d/1cWZmDik5PlWaEd-srekTiF51chDR8b7_/view?usp=share_link
> > > > BTW this link is also in the downloads section of BugsBoard_Primer.pdf at https://drive.google.com/file/d/14iPt_j_lmINSs4cte3_MneA6D4UCBjZi/view?usp=sharing
> > > > I tried to convey this info in my kickoff post, but I'm a geek, not a salesman.
> > > I looked at the file. You wish to use opposite edges of the clock for read and write.
> > >
> > > Before I make any comments, I want to ask, why was it necessary for me to read the file in order for you to ask a question?
> > For the same reason that I follow links posted here before I add my 2 cents. Otherwise, I wouldn't know what questions to ask, or have a factual basis for my opinion. Was it such an ordeal viewing 25 lines of Verilog?
> It was pointless, just as this entire discussion. You seem to enjoy distracting from the conversation, rather than promoting a conversation. You posted that you didn't like a board, without explaining why. When asked, rather than saying, you need to clock on opposite edges of the clock, you travel down a rabbit hole of obstruction.
>
> In the end, I found that your complaint is baseless. You don't seem to understand block RAMs, or at least don't understand the Gowin BRAMs. Did you try synthesizing this file? Again, no information from you on this.
>
> You didn't post your 2 cents. You posted noise.
>
> In response to your file, what you would use is Semi-Dual Port Mode.
>
> Now, learn how to have a discussion rather than being a bit of a jerk. Oh, and you are welcome for the advice on how to use the Gowin BRAM.
>
> --
>
> Rick C.
>
> --- Get 1,000 miles of free Supercharging
> --- Tesla referral code - https://ts.la/richard11209

There is you again who puts his nasty-guy hat on.

Your reading capabilities seem to have unfortunately dedetiorated drastically.

Myron explained it all.
Everything Myron posted made sense.

And the link was in his first post.
BugsBoard_Primer.pdf is at https://drive.google.com/file/d/14iPt_j_lmINSs4cte3_MneA6D4UCBjZi/view?usp=sharing
A link to Bugs18bis.zip is in the downloads section.
Cheers - Myron Plichota

GET YOUR READING GLASSES.

And Happy Christmas Season to everbody else.

On Friday, December 9, 2022 at 9:57:47 AM UTC-4, jpit...@gmail.com wrote:
> On Friday, 9 December 2022 at 11:50:24 UTC, gnuarm.del...@gmail.com wrote:
> > On Friday, December 9, 2022 at 6:14:50 AM UTC-4, Myron Plichota wrote:
> > > On Thursday, December 8, 2022 at 10:13:04 AM UTC-5, gnuarm.del...@gmail.com wrote:
> > > > On Thursday, December 8, 2022 at 5:36:59 AM UTC-4, Myron Plichota wrote:
> > > > > Bugs18bis.zip is at https://drive.google.com/file/d/1cWZmDik5PlWaEd-srekTiF51chDR8b7_/view?usp=share_link
> > > > > BTW this link is also in the downloads section of BugsBoard_Primer.pdf at https://drive.google.com/file/d/14iPt_j_lmINSs4cte3_MneA6D4UCBjZi/view?usp=sharing
> > > > > I tried to convey this info in my kickoff post, but I'm a geek, not a salesman.
> > > > I looked at the file. You wish to use opposite edges of the clock for read and write.
> > > >
> > > > Before I make any comments, I want to ask, why was it necessary for me to read the file in order for you to ask a question?
> > > For the same reason that I follow links posted here before I add my 2 cents. Otherwise, I wouldn't know what questions to ask, or have a factual basis for my opinion. Was it such an ordeal viewing 25 lines of Verilog?
> > It was pointless, just as this entire discussion. You seem to enjoy distracting from the conversation, rather than promoting a conversation. You posted that you didn't like a board, without explaining why. When asked, rather than saying, you need to clock on opposite edges of the clock, you travel down a rabbit hole of obstruction.
> >
> > In the end, I found that your complaint is baseless. You don't seem to understand block RAMs, or at least don't understand the Gowin BRAMs. Did you try synthesizing this file? Again, no information from you on this.
> >
> > You didn't post your 2 cents. You posted noise.
> >
> > In response to your file, what you would use is Semi-Dual Port Mode.
> >
> > Now, learn how to have a discussion rather than being a bit of a jerk. Oh, and you are welcome for the advice on how to use the Gowin BRAM.
> >
> > --
> >
> > Rick C.
> >
> > --- Get 1,000 miles of free Supercharging
> > --- Tesla referral code - https://ts.la/richard11209
> There is you again who puts his nasty-guy hat on.
>
> Your reading capabilities seem to have unfortunately dedetiorated drastically.
>
> Myron explained it all.
> Everything Myron posted made sense.
>
> And the link was in his first post.
> BugsBoard_Primer.pdf is at https://drive.google.com/file/d/14iPt_j_lmINSs4cte3_MneA6D4UCBjZi/view?usp=sharing
> A link to Bugs18bis.zip is in the downloads section.
> Cheers - Myron Plichota
> GET YOUR READING GLASSES.

I can't be wearing the nasty hat. Because you wear it so much, it's all stretched out and doesn't fit anyone else's head. If you had actually read the post you replied to, you might understand what I was commenting about.

The reality is Myron doesn't understand the Gowin BSRAM. That was the point. Rather than ask me a simple question about how to use the Gowin BRAM, he drags it out like a drama queen. Then when I finally find out that the issue was about Myron not understanding the parts and giving Gowin a black eye with his false comments, I explained the point to him. Was I rude, not really. Was I sweet as pie, no, not at all. I don't have patience for drama queens. You are at the top of that list. You mainly come to this group to create drama. If that were not true, you would ignore this entire post.. But I know you can't resist an opportunity to create more drama. So have at it!

The Gowin BSRAM will support a read port and a write port with separate data and clocks. For an unknown reason, Myron thought that would be supported in single port mode. The very wording of "single" port mode says you can't have two of anything. Dual port mode will support his RAM file, except there is one configuration of address and data bus size that is not available, 32/36 bit data. The semi-dual port mode with two separate interfaces for read and write, are exactly what Myron is describing in his HDL file, but did not understand.

Now you both know and have no reason to complain. But I'm sure you will find plenty to complain about. That's what you do, oh so well. But in any event, you are welcome for the lesson in Gowin BSRAMs.

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

On Friday, December 9, 2022 at 4:59:06 PM UTC-5, gnuarm.del...@gmail.com wrote:
[snip]

Thanks for your kind defence, Juergen.

[snip]
> The reality is Myron doesn't understand the Gowin BSRAM. That was the point. Rather than ask me a simple question about how to use the Gowin BRAM, he drags it out like a drama queen. Then when I finally find out that the issue was about Myron not understanding the parts and giving Gowin a black eye with his false comments, I explained the point to him. Was I rude, not really. Was I sweet as pie, no, not at all. I don't have patience for drama queens. You are at the top of that list. You mainly come to this group to create drama. If that were not true, you would ignore this entire post. But I know you can't resist an opportunity to create more drama. So have at it!
>
> The Gowin BSRAM will support a read port and a write port with separate data and clocks. For an unknown reason, Myron thought that would be supported in single port mode. The very wording of "single" port mode says you can't have two of anything. Dual port mode will support his RAM file, except there is one configuration of address and data bus size that is not available, 32/36 bit data. The semi-dual port mode with two separate interfaces for read and write, are exactly what Myron is describing in his HDL file, but did not understand.
>
> Now you both know and have no reason to complain. But I'm sure you will find plenty to complain about. That's what you do, oh so well. But in any event, you are welcome for the lesson in Gowin BSRAMs.
[snip]

Well at least I pointed and clicked and registered a new Gowin account (had to give the bastards my email@) and downloaded the datasheet and searched within for BRAM info and spent a few minutes assessing the graphics and text. After repeated views, I still do not recommend this FPGA for a BugsBoard transplant. Semi dual port mode is not a solution to my design problem.

OTOH, the datasheets for Lattice iCE40 and Xilinx Series 7 FPGAs show single-port BRAM modes with selectable clock polarity for the read and write clocks. Bingo, the solution to my design problem, i.e. make synchronous BRAM yield any random read with 1-clock latency (0 wait states, no CPU stalls). ram1c.v *infers* correct single-port BRAM aggregates using the Lattice iCEcube2 and Xilinx Vivado ML 2021.1 toolchains, as proven by multiple projects.

But don't let me hold you back, Rick. I hope that someday you will publish solutions you are humbly proud of.

"Jimbo is not James Bond, except when he is." - an ancient koan

On Saturday, 10 December 2022 at 00:56:36 UTC, Myron Plichota wrote:
> On Friday, December 9, 2022 at 4:59:06 PM UTC-5, gnuarm.del...@gmail.com wrote:
> [snip]
>
> Thanks for your kind defence, Juergen.
>
> [snip]
> > The reality is Myron doesn't understand the Gowin BSRAM. That was the point. Rather than ask me a simple question about how to use the Gowin BRAM, he drags it out like a drama queen. Then when I finally find out that the issue was about Myron not understanding the parts and giving Gowin a black eye with his false comments, I explained the point to him. Was I rude, not really. Was I sweet as pie, no, not at all. I don't have patience for drama queens. You are at the top of that list. You mainly come to this group to create drama. If that were not true, you would ignore this entire post. But I know you can't resist an opportunity to create more drama. So have at it!
> >
> > The Gowin BSRAM will support a read port and a write port with separate data and clocks. For an unknown reason, Myron thought that would be supported in single port mode. The very wording of "single" port mode says you can't have two of anything. Dual port mode will support his RAM file, except there is one configuration of address and data bus size that is not available, 32/36 bit data. The semi-dual port mode with two separate interfaces for read and write, are exactly what Myron is describing in his HDL file, but did not understand.
> >
> > Now you both know and have no reason to complain. But I'm sure you will find plenty to complain about. That's what you do, oh so well. But in any event, you are welcome for the lesson in Gowin BSRAMs.
> [snip]
>
> Well at least I pointed and clicked and registered a new Gowin account (had to give the bastards my email@) and downloaded the datasheet and searched within for BRAM info and spent a few minutes assessing the graphics and text. After repeated views, I still do not recommend this FPGA for a BugsBoard transplant. Semi dual port mode is not a solution to my design problem.
>
> OTOH, the datasheets for Lattice iCE40 and Xilinx Series 7 FPGAs show single-port BRAM modes with selectable clock polarity for the read and write clocks. Bingo, the solution to my design problem, i.e. make synchronous BRAM yield any random read with 1-clock latency (0 wait states, no CPU stalls). ram1c.v *infers* correct single-port BRAM aggregates using the Lattice iCEcube2 and Xilinx Vivado ML 2021.1 toolchains, as proven by multiple projects.
>
> But don't let me hold you back, Rick. I hope that someday you will publish solutions you are humbly proud of.
>
> "Jimbo is not James Bond, except when he is." - an ancient koan

ANOTHER BULLSHIT POST OF YOURS
Myron is great.

Get real
Live with it

On Friday, December 9, 2022 at 8:56:36 PM UTC-4, Myron Plichota wrote:
> On Friday, December 9, 2022 at 4:59:06 PM UTC-5, gnuarm.del...@gmail.com wrote:
> [snip]
>
> Thanks for your kind defence, Juergen.
>
> [snip]
> > The reality is Myron doesn't understand the Gowin BSRAM. That was the point. Rather than ask me a simple question about how to use the Gowin BRAM, he drags it out like a drama queen. Then when I finally find out that the issue was about Myron not understanding the parts and giving Gowin a black eye with his false comments, I explained the point to him. Was I rude, not really. Was I sweet as pie, no, not at all. I don't have patience for drama queens. You are at the top of that list. You mainly come to this group to create drama. If that were not true, you would ignore this entire post. But I know you can't resist an opportunity to create more drama. So have at it!
> >
> > The Gowin BSRAM will support a read port and a write port with separate data and clocks. For an unknown reason, Myron thought that would be supported in single port mode. The very wording of "single" port mode says you can't have two of anything. Dual port mode will support his RAM file, except there is one configuration of address and data bus size that is not available, 32/36 bit data. The semi-dual port mode with two separate interfaces for read and write, are exactly what Myron is describing in his HDL file, but did not understand.
> >
> > Now you both know and have no reason to complain. But I'm sure you will find plenty to complain about. That's what you do, oh so well. But in any event, you are welcome for the lesson in Gowin BSRAMs.
> [snip]
>
> Well at least I pointed and clicked and registered a new Gowin account (had to give the bastards my email@) and downloaded the datasheet and searched within for BRAM info and spent a few minutes assessing the graphics and text. After repeated views, I still do not recommend this FPGA for a BugsBoard transplant. Semi dual port mode is not a solution to my design problem.

How is that exactly? Why do you make comments like this without explaining?

I would point out that you don't need to worry with what mode the device uses. You specify your HDL, and the tools generate a design to suit.

> OTOH, the datasheets for Lattice iCE40 and Xilinx Series 7 FPGAs show single-port BRAM modes with selectable clock polarity for the read and write clocks. Bingo, the solution to my design problem, i.e. make synchronous BRAM yield any random read with 1-clock latency (0 wait states, no CPU stalls). ram1c.v *infers* correct single-port BRAM aggregates using the Lattice iCEcube2 and Xilinx Vivado ML 2021.1 toolchains, as proven by multiple projects.

If there are read and write ports, it's NOT single port! That's the definition of dual port, multiple ports. In this case, one for reads and one for writes.

> But don't let me hold you back, Rick. I hope that someday you will publish solutions you are humbly proud of.

I should simply accept that you do not wish to discuss this, rather you are just being a troll.

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

Poo itto baby can't undertand Bugs18bis.zip.

On Saturday, December 10, 2022 at 9:50:36 AM UTC-4, Myron Plichota wrote:
> Poo itto baby can't undertand Bugs18bis.zip.

So not only can you not explain your problem, just thinking about it reduces you to baby talk?

Dude, you are a trip!

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209

On Saturday, December 10, 2022 at 9:57:46 AM UTC-5, gnuarm.del...@gmail.com wrote:
> On Saturday, December 10, 2022 at 9:50:36 AM UTC-4, Myron Plichota wrote:
> > Poo itto baby can't undertand Bugs18bis.zip.
> So not only can you not explain your problem, just thinking about it reduces you to baby talk?
>
> Dude, you are a trip!

I'm on a very good trip that defies explaining color to a blind man.

On Saturday, December 10, 2022 at 1:10:51 PM UTC-4, Myron Plichota wrote:
> On Saturday, December 10, 2022 at 9:57:46 AM UTC-5, gnuarm.del...@gmail.com wrote:
> > On Saturday, December 10, 2022 at 9:50:36 AM UTC-4, Myron Plichota wrote:
> > > Poo itto baby can't undertand Bugs18bis.zip.
> > So not only can you not explain your problem, just thinking about it reduces you to baby talk?
> >
> > Dude, you are a trip!
> I'm on a very good trip that defies explaining color to a blind man.

Instead of all the crap, why not just answer the question? What is it about the Gowin BSRAM that makes you say, "Semi dual port mode is not a solution to my design problem."

--

Rick C.

+-- Get 1,000 miles of free Supercharging
+-- Tesla referral code - https://ts.la/richard11209

On Saturday, December 10, 2022 at 1:56:41 PM UTC-5, gnuarm.del...@gmail.com wrote:
> Instead of all the crap, why not just answer the question? What is it about the Gowin BSRAM that makes you say, "Semi dual port mode is not a solution to my design problem."

1) You don't appear to have an interest in performing a BugsBoard transplant.
2) Even if you do, you deserve to fail.

On Monday, 12 December 2022 at 01:12:21 UTC, Myron Plichota wrote:
> On Saturday, December 10, 2022 at 1:56:41 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > Instead of all the crap, why not just answer the question? What is it about the Gowin BSRAM that makes you say, "Semi dual port mode is not a solution to my design problem."
> 1) You don't appear to have an interest in performing a BugsBoard transplant.
> 2) Even if you do, you deserve to fail.

What an ugly character this guy is.
But the Forth community here has to live him/it until he dies,
or he gets more direct feedback from others here and leaves to bother other groups that cannot throw him/it out.

A little statistic regardig this post:

327 people looked at it
7 people reacted and posted

So, I think this is a great post of yours, especially when Verilog can be expressed in Forth;
but for now it might be actually the wrong group to post it in as the reaction shows.

On Monday, December 12, 2022 at 2:38:09 AM UTC-5, Jurgen Pitaske wrote:
> On Monday, 12 December 2022 at 01:12:21 UTC, Myron Plichota wrote:
> > On Saturday, December 10, 2022 at 1:56:41 PM UTC-5, gnuarm.del...@gmail..com wrote:
> > > Instead of all the crap, why not just answer the question? What is it about the Gowin BSRAM that makes you say, "Semi dual port mode is not a solution to my design problem."
> > 1) You don't appear to have an interest in performing a BugsBoard transplant.
> > 2) Even if you do, you deserve to fail.
> What an ugly character this guy is.
> But the Forth community here has to live him/it until he dies,
> or he gets more direct feedback from others here and leaves to bother other groups that cannot throw him/it out.
>
> A little statistic regardig this post:
>
> 327 people looked at it
> 7 people reacted and posted
>
> So, I think this is a great post of yours, especially when Verilog can be expressed in Forth;
> but for now it might be actually the wrong group to post it in as the reaction shows.

I admit that I opened my mouth on clf while my success was fresh and the proven volume of BugsBoard working code was in its infancy. This was intentional because I had no wish to subject the audience to a dumptruck load of source code, and I wanted to see what flak would result before I proceeded on my merry way. I risked learning something, and I did indeed learn about the proverbial crabs in the bucket.

The pedantic legalist, Lorem Ipsum (signed Rick C.) more or less demanded an essay from me on why I don't recommend his favorite Gowin FPGA for a BugsBoard transplant, and I counter-challenged him to understand the proven Verilog that resulted in actual 1 clock cycle random read access of *synchronous* FPGA RAM proven on Lattice iCE40 and Xilinx Spartan 7 implementations. I noticed on another thread that he, in a rare moment of humility, admitted that he is a VHDL guy, and does not understand Verilog. Yet he declared me to be a troll. (Oh the irony!)

I am inclined towards charity, so I will share with Rick a clue: the Gowin "Semi Dual Port" RAM mode as portrayed in section 3.4.8 of the official datasheet does not suggest a viable solution of ram1c.v because unlike the iCE40 and Spartan 7 datasheets, there is no way to bypass a pipeline register in the read path. Perhaps despite my grasp of iCE40 and Spartan 7 datasheets, Rick will ace me at my own game with something like ram1c.v on the Gowin silicon, and I would love to read of his success in realizing similar clock-by-clock performance in the HDL language of choice. But I am not holding my breath to see the day.

I see 3 persistent efforts to rub Forth programmers' noses in reality:
1) improving virtual machines on 64-bit commodity desktop/laptop hardware
2) improving virtual machines on 16 or 32-bit commodity microcontroller hardware
3) implementing native machines on FPGAs that bypass all of the above

I am of the #3 persuasion, but I have total respect for those persuing #1 and #2.

The opportunity for Forth to take over ze veld is long gone. The C bastards won, and as an admitted acceptor of the aftermath, I have found it expedient to find a way to advance my agenda, even unto resorting to designing hardware in Verilog, and generating code for said hardware using Python3.

Chuck Moore created the original monster, and has inspired me to do my best to bite off chunks that I can chew.

I wish that clf culture relaxed a wee bit and became famous for promoting the merits of fundamental Forth programming precepts.

On Sunday, August 20, 2023 at 6:35:21 PM UTC-7, Myron Plichota wrote:
> I wish that clf culture relaxed a wee bit and became famous for promoting
> the merits of fundamental Forth programming precepts.

I remember that I told you about Testra's MiniForth built on the Lattice
isp1048 PLD in 1995 and how it held the data-stack in external memory.
My processor design also holds the data-stack in memory (internal now).
You said that myself and everybody at Testra should take a Programming-101
class to learn basic programming concepts. You seem to think that the only
viable solution for a Forth processor is to hold the entire data-stack in
cell flip-flops so that Forth words such as DUP SWAP OVER + etc. can be
single clock-cycle. The data-stack would be fairly small, like 8 elements.
There are actually serious problems with this technique. For one thing,
you can't have ISRs because you have no way to save/restore the Forth context.
I think that you could really relax a wee bit too --- dial down the arrogance!

The MiniForth was used in a a motion-control board that was less-expensive
and higher-performing than the competition's motion-control board that used
an MC68000 programmed in C. Has the Bugs18 processor ever competed
successfully with C? Has it ever been used in a real-world application?
This is the year 2023 --- the MiniForth came out in 1995 --- nobody in the
Forth community has come up with anything comparable after three decades.

Your Bugs18 has a 6-bit opcode, so there are 64 instructions.
That is not very many! There is no future in a processor with only 64
instructions --- this is a toy --- it will never be used for real-world applications.

On Sunday, August 20, 2023 at 10:09:02 PM UTC-4, Hugh Aguilar wrote:
> On Sunday, August 20, 2023 at 6:35:21 PM UTC-7, Myron Plichota wrote:
> > I wish that clf culture relaxed a wee bit and became famous for promoting
> > the merits of fundamental Forth programming precepts.
> I remember that I told you about Testra's MiniForth built on the Lattice
> isp1048 PLD in 1995 and how it held the data-stack in external memory.
> My processor design also holds the data-stack in memory (internal now).
> You said that myself and everybody at Testra should take a Programming-101
> class to learn basic programming concepts. You seem to think that the only
> viable solution for a Forth processor is to hold the entire data-stack in
> cell flip-flops so that Forth words such as DUP SWAP OVER + etc. can be
> single clock-cycle. The data-stack would be fairly small, like 8 elements..
> There are actually serious problems with this technique. For one thing,
> you can't have ISRs because you have no way to save/restore the Forth context.
> I think that you could really relax a wee bit too --- dial down the arrogance!
>
> The MiniForth was used in a a motion-control board that was less-expensive
> and higher-performing than the competition's motion-control board that used
> an MC68000 programmed in C. Has the Bugs18 processor ever competed
> successfully with C? Has it ever been used in a real-world application?
> This is the year 2023 --- the MiniForth came out in 1995 --- nobody in the
> Forth community has come up with anything comparable after three decades.
>
> Your Bugs18 has a 6-bit opcode, so there are 64 instructions.
> That is not very many! There is no future in a processor with only 64
> instructions --- this is a toy --- it will never be used for real-world applications.

Hi Hugh, you has been troll!

Bugs18 in fact has a mere 4-bit opcode per slot and runs on my bench performing real-time audio programs, not that you care about the facts.

On Sunday, August 20, 2023 at 10:09:02 PM UTC-4, Hugh Aguilar wrote:
> On Sunday, August 20, 2023 at 6:35:21 PM UTC-7, Myron Plichota wrote:
> > I wish that clf culture relaxed a wee bit and became famous for promoting
> > the merits of fundamental Forth programming precepts.
> I remember that I told you about Testra's MiniForth built on the Lattice
> isp1048 PLD in 1995 and how it held the data-stack in external memory.
> My processor design also holds the data-stack in memory (internal now).
> You said that myself and everybody at Testra should take a Programming-101
> class to learn basic programming concepts. You seem to think that the only
> viable solution for a Forth processor is to hold the entire data-stack in
> cell flip-flops so that Forth words such as DUP SWAP OVER + etc. can be
> single clock-cycle.

Using distributed RAM or "cell FFs" is not required for single cycle instructions. The BRAM available in most FPGA allow two port access, where one can read and the other write if that is required. But most stack CPU designers keep the top of stack in a register anyway, and often the next on stack as well. So, technically these are "cell FFs", but only for the top and possibly next to top of stack. But they are not required. Dual access can provide two reads and one write on the same clock cycle.

> The data-stack would be fairly small, like 8 elements.
> There are actually serious problems with this technique. For one thing,
> you can't have ISRs because you have no way to save/restore the Forth context.
> I think that you could really relax a wee bit too --- dial down the arrogance!
>
> The MiniForth was used in a a motion-control board that was less-expensive
> and higher-performing than the competition's motion-control board that used
> an MC68000 programmed in C. Has the Bugs18 processor ever competed
> successfully with C? Has it ever been used in a real-world application?
> This is the year 2023 --- the MiniForth came out in 1995 --- nobody in the
> Forth community has come up with anything comparable after three decades.

Mostly because the MiniForth is a specialized processor. Not so many designers want to mess with the issues of using such a processor, when they can use off the shelf processors to do the job.

> Your Bugs18 has a 6-bit opcode, so there are 64 instructions.
> That is not very many! There is no future in a processor with only 64
> instructions --- this is a toy --- it will never be used for real-world applications.

??? There are a number of stack processors with 5 bit instructions which are used in volume applications in ASICs. I believe the b16 is one of those.. Or maybe the instructions are 4 bits, I don't recall.

Why can't stack processors with small instructions be useful in real world applications?

--

Rick C.

+-+ Get 1,000 miles of free Supercharging
+-+ Tesla referral code - https://ts.la/richard11209

> Why can't stack processors with small instructions be useful in real world applications?

I have demonstrated that they are up to audio bandwidth.

On Monday, August 21, 2023 at 12:37:21 AM UTC-4, Myron Plichota wrote:
> > Why can't stack processors with small instructions be useful in real world applications?
> I have demonstrated that they are up to audio bandwidth.

Is your processor single clock per instruction? What is the max clock rate?

--

Rick C.

++- Get 1,000 miles of free Supercharging
++- Tesla referral code - https://ts.la/richard11209

> Is your processor single clock per instruction? What is the max clock rate?
Yes. A modest 48 MHz.

On Monday, August 21, 2023 at 1:48:44 AM UTC-4, Myron Plichota wrote:
> > Is your processor single clock per instruction? What is the max clock rate?
> Yes. A modest 48 MHz.

That's a promising capability. I recall a couple of families of audio processors for hearing aids, that were just designed to handle the signal processing, such as filters. The architecture was a linear set of instructions, which might have had some looping capability (hard to think it wouldn't). It was designed to capture an ADC sample and run through the code once, lather, rinse, repeat.

I never obtained details of the instructions or architecture, because the makers were mainly interested in large buyer. My production quantities range around 1,000 to 3,000 units per year these days, not enough to interest these guys.

I always appealed to me. They were pretty low power and clearly optimized for audio work. One supplier was ADI. I took a quick look, and the units I had seen seem to be out of date now. Here's one that's pretty powerful.

https://www.onsemi.com/download/data-sheet/pdf/e7111-d.pdf

There's lots of stuff on the market.

--

Rick C.

+++ Get 1,000 miles of free Supercharging
+++ Tesla referral code - https://ts.la/richard11209

On Monday, August 21, 2023 at 3:45:25 AM UTC-4, Lorem Ipsum wrote:
> On Monday, August 21, 2023 at 1:48:44 AM UTC-4, Myron Plichota wrote:
> > > Is your processor single clock per instruction? What is the max clock rate?
> > Yes. A modest 48 MHz.
> That's a promising capability. I recall a couple of families of audio processors for hearing aids, that were just designed to handle the signal processing, such as filters. The architecture was a linear set of instructions, which might have had some looping capability (hard to think it wouldn't). It was designed to capture an ADC sample and run through the code once, lather, rinse, repeat.
>
> I never obtained details of the instructions or architecture, because the makers were mainly interested in large buyer. My production quantities range around 1,000 to 3,000 units per year these days, not enough to interest these guys.
>
> I always appealed to me. They were pretty low power and clearly optimized for audio work. One supplier was ADI. I took a quick look, and the units I had seen seem to be out of date now. Here's one that's pretty powerful.
>
> https://www.onsemi.com/download/data-sheet/pdf/e7111-d.pdf
>
> There's lots of stuff on the market.

Nothing beats an ASIC for a theoretical market advantage. BugsBoard can only offer a user with a high-performance platform that enlists the Python3 front end to generate code for the underlying Forth CPU (that lo and behold, does not suck at DSP algorithms). My question to anyone reading this is: Would you want your daughter to marry a BugsBoard programmer in these times?