2022-07-07 07:09:28 <boru        > There are still some around, yeah. CPLDs and PLCs still turn up in my line of work.
2022-07-07 09:40:04 <KipIngram   > Do you have a link to one handy?  Or just a part number; I can find it.  I'm just curious what the lay of the land is these days.
2022-07-07 09:41:10 <KipIngram   > I remember quite liking those AMD MACH parts.  They were the first ones (I was exposed to) that had kind of a "next level" of complexity to them.  There was a routing "hierarchy" instead of just a straight and/or grid.  So they gave you a pretty good playground for "creative thinking."
2022-07-07 09:42:13 <KipIngram   > With the simpler ones, it was generally a sort of "it either fits or it doesn't" matter.  But with the MACH parts there was room for seeking a "clever architecture."
2022-07-07 09:45:08 <KipIngram   > And one thing that was nice back in those day sis that you found stuff like THIS in the product literature:
2022-07-07 09:45:11 <KipIngram   > Extensive third-party software and programmer support through FusionPLD(SM) partners
2022-07-07 09:45:33 <KipIngram   > As opposed to the closed proprietary ecosystems FPGA manufacturers pursue.
2022-07-07 09:47:28 <KipIngram   > With the really early PLDs you could use DEBUG to modify the fuse files if you wanted to.
2022-07-07 09:47:53 <KipIngram   > There was a picture in the documentation of the and/or grid, and you could actually see the bits in the fuse file corresponding to that.
2022-07-07 09:49:06 <KipIngram   > One of the common pieces of software used to make those fuse files was called ABLE, and we once caught ABLE making a mistake.  It just wasn't programming the part correctly, per our equations.  So we DEBUGed the file and changed the one wrong bit and burned another part - problem solved.
2022-07-07 09:51:38 <KipIngram   > Maybe it was ABEL.  Can't really remember.
2022-07-07 09:51:53 <thrig       > then you could add BAKER and CHARLIE
2022-07-07 09:52:03 <KipIngram   > Yeah -
2022-07-07 09:52:04 <Zarutian_HTC> unABLE to recall, eh?
2022-07-07 09:52:05 <KipIngram   > https://en.wikipedia.org/wiki/Advanced_Boolean_Expression_Language
2022-07-07 09:52:09 <KipIngram   > Heh heh.
2022-07-07 09:53:07 <KipIngram   > For a couple of years in there, when the FPGA companies first started to think about monetizing their software, I was able to wangle free seats, by just telling my outside sales rep that they wouldn't be selling us the parts unless they equipped us to develop with them.
2022-07-07 09:53:26 <KipIngram   > I suspect at that time the parts and the software sent money into the same "division" or whatever.
2022-07-07 09:53:45 <KipIngram   > and then later it got split up, and that leverage no longer worked, because the software group couldn't care less about how many parts got sold.
2022-07-07 09:54:24 <KipIngram   > But that notion of buying software so that we could then buy parts stuck in my craw really hard.
2022-07-07 09:54:37 <KipIngram   > At the time it just felt "legitimately wrong" to me.
2022-07-07 09:54:47 <KipIngram   > "Do you want us to use your parts or not?"
2022-07-07 09:58:38 <Zarutian_HTC> and what is it with them insisting on making more and more 'hard cores' into their fpgas?
2022-07-07 10:02:36 <KipIngram   > Well, hard cores are more compact than the same functionality in a generically routable implementation.  So IF YOU NEED those hard cores, you're better off / the device can be cheaper / etc.  They're trying to guess what combination of hard features will entice the most money out of the market.
2022-07-07 10:04:24 <KipIngram   > So I guess their "guess" is that more customers will want that particular hard core than won't.
2022-07-07 10:04:46 <Zarutian_HTC> that is the thing, the exact cores are not needed but a tweaked versions of them are
2022-07-07 10:05:19 <KipIngram   > Say you design a product that has a big generic FPGA and a microprocessor.  Well, if you can get that microprocessor on the same chip as the FPGA, that's advantageous to you.  At the very least you shrunk your BOM.
2022-07-07 10:05:43 <KipIngram   > Right, I basically agree with you - I don't think it's really possible to predict what the market wants that well.
2022-07-07 10:05:48 <KipIngram   > Doesn't stop them from trying.
2022-07-07 10:06:41 <Zarutian_HTC> the thing is that 'in-built' microproccessor might not be of same architecture as the seperate one
2022-07-07 10:06:42 <KipIngram   > More people buy homesites with houses already built on them than not.  Same idea?
2022-07-07 10:06:53 <KipIngram   > Sure.
2022-07-07 10:07:19 <KipIngram   > But, why would anyone want a pre-built house, when they could build their own and get it just the way they want it?
2022-07-07 10:07:37 <Zarutian_HTC> depends on the cost of building in the case of houses
2022-07-07 10:08:08 <KipIngram   > It does.  Not a perfect analogy, but there's at least a little simialrity.  And yeah - fab homes are cheaper to build than custom ones.
2022-07-07 10:08:22 <KipIngram   > But, a hard core will consume less silicon than a comparable soft core.
2022-07-07 10:08:50 <Zarutian_HTC> depends on what the config memory is made of
2022-07-07 10:09:31 <KipIngram   > I guess one way of looking at it is that routing logic in an FPGA is "overhead."  I mean, it allows you to make the device the way you want it, but then it just "sits there taking up space."  It doesn't WORK for you the way the active logic does.
2022-07-07 10:09:46 <KipIngram   > So the less routing logic you need to get to your finish line, the more room you have for working logic.
2022-07-07 10:10:17 <KipIngram   > But like I said, I agree with you.  I've never had much interest in core-laden FPGAs.
2022-07-07 10:10:26 <KipIngram   > Just give me my configurable logic, please.
2022-07-07 10:11:22 <Zarutian_HTC> btw these core laden fpgas are often more expensive than fpgas with less of such in it
2022-07-07 10:11:29 <KipIngram   > Yeah, I know.
2022-07-07 10:11:44 <KipIngram   > Whoever owns the core has to get paid too.
2022-07-07 10:11:54 <KipIngram   > It's become a huge complicated mess.
2022-07-07 10:12:26 <Zarutian_HTC> okay, I understand cores like block rams are nice to have but leave out the shitty microprocessors
2022-07-07 10:12:29 <KipIngram   > What I really wish, though, is that the whole thing was "wide open."  Tell me EVERYTHING about the part I'm buying, so I can come up with any clever idea I want to.
2022-07-07 10:12:45 <KipIngram   > I've always felt like there's probably a lot of innovation to be had via "on the fly reconfiguration."
2022-07-07 10:13:01 <KipIngram   > but it's hard to do that when they won't tell you how the configuration works, and when you can't randomly access it.
2022-07-07 10:13:15 <KipIngram   > Your BitGrid is the "ultimate" on that spectrum.
2022-07-07 10:13:39 <Zarutian_HTC> well BitGrid isnt mine though
2022-07-07 10:14:14 <KipIngram   > Oh, I know, but you've evangelized it here; that's all I meant.
2022-07-07 10:14:36 <Zarutian_HTC> just the idea of having say 20x20 BitGrid blocks with AVR whosenamewasit FPGA routing fabric between them
2022-07-07 10:14:49 <KipIngram   > But being able to change your logic, anytime, to suit the situation your facing RIGHT NOW - that seems like an obvious good thing.
2022-07-07 10:15:33 <KipIngram   > Of course, that idea is highly frowned on in software.  :-)
2022-07-07 10:15:44 <Zarutian_HTC> Bitgrid.blogspot.com for those interested
2022-07-07 10:16:42 <Zarutian_HTC> really? ya not heard of JITing with Ahead Compiled code caches?
2022-07-07 10:17:18 <KipIngram   > Vaguely, but I've not pusued any details.  I was just referring to the general condemnation of self-modifying code.
2022-07-07 10:17:28 <Zarutian_HTC> or partial evaluation used in Dr. Futamuras three projections?
2022-07-07 10:17:36 <KipIngram   > No, haven't heard of that one at all.
2022-07-07 10:17:53 <thrig       > self-modifying code can be fun to debug
2022-07-07 10:19:22 <Zarutian_HTC> http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html
2022-07-07 10:49:02 <KipIngram   > That's kind of fun.
2022-07-07 11:31:22 <KipIngram   > Looks like some of the Lattice ICE family devices have been pattern reverse engineered and open source toolchains exist.
2022-07-07 11:31:37 <KipIngram   > I saw another one a few months ago.
2022-07-07 12:01:18 <KipIngram   > symbiflow
2022-07-07 12:01:50 <KipIngram   > I found it to be rather... "monstrous," and it also operates within some kind of weird "overlay environment" that I think had to do with anaconda.
2022-07-07 12:02:05 <KipIngram   > I know it changed my bash prompt, which kind of weirded me out.
2022-07-07 12:05:07 <KipIngram   > There's a good overview of open source tools here:
2022-07-07 12:05:09 <KipIngram   > https://fpgatutorial.com/open-source-fpga-tools/
2022-07-07 13:10:50 <KipIngram   > Wow - the j1 cpu source is impressively small.
2022-07-07 13:32:15 <Zarutian_HTC> indeed
2022-07-07 13:33:26 <Zarutian_HTC> when I first saw it I thought: great, one more of these that split their source into gazillion tiny files and do opaque includes
2022-07-07 13:33:49 <Zarutian_HTC> but then I realized it is indeed this small
2022-07-07 13:40:38 <KipIngram   > Yeah - plenty small enough to get your head around.
2022-07-07 13:41:12 <KipIngram   > Do you have any calibration on the price of the smallest FPGA it'll fit in?
2022-07-07 13:42:54 <KipIngram   > I like the way it folds the return operation into any ALU operation.
2022-07-07 13:43:19 <thrig       > oh j1 became https://github.com/howerj/forth-cpu and then https://github.com/howerj/embed
2022-07-07 13:43:29 <KipIngram   > And of course if the last op is a call, you can tail optimize it into a jump.  So basically all returns are free.
2022-07-07 13:43:37 <KipIngram   > Oh, that's a different repo from the one I found.
2022-07-07 13:44:08 <KipIngram   > Hmmm.  That's an altogether different guy.
2022-07-07 13:44:28 <KipIngram   > I found it here:
2022-07-07 13:45:18 <KipIngram   > https://github.com/jamesbowman/j1
2022-07-07 13:46:06 <KipIngram   > When I was playing with a hardware Forth my returns wound up being free too, so that just seems to be a feature the language lends itself to.
2022-07-07 13:46:22 <KipIngram   > That and single-cycle calls.
2022-07-07 13:50:28 <KipIngram   > Looks like j1 uses non-encoded instructions.  So code density wouldn't be as low as it might be, but on the other hand it doesn't need to pipeline to get one cycle instruction execution either.
2022-07-07 14:01:33 <KipIngram   > I used 5-bit encoded and packed instructions in mine.  So the return operation did require an opcode slot.  But the hardware would "see it coming" and respond to it while the previous instruction executed, so it was free so far as execution time went.
2022-07-07 16:05:51 <KipIngram   > thrig: Hey, that embed stuff built without a hitch and just fired right up.
2022-07-07 16:05:53 <KipIngram   > Nice.
2022-07-07 16:07:12 <thrig       > there's a bug if you push before doing anything, probably need to poke the author about that again
2022-07-07 16:08:10 <KipIngram   > Push - you mean if you put something on the stack?
2022-07-07 16:15:53 <thrig       > if you embed_push(&engine, 42) before doing embed_eval(&engine, "whatever") the pushes get lost or something
2022-07-07 16:18:51 <thrig       > https://github.com/howerj/embed/issues/10
2022-07-07 16:47:10 <KipIngram   > Ah.
2022-07-07 16:47:32 <KipIngram   > I just ran it from the console and typed into it.
2022-07-07 16:47:53 <KipIngram   > Noticed that they didn't diddle the termios to get "standard Forth behavior."
2022-07-07 16:48:04 <KipIngram   > Looks like they just use the read system call straight out of the box.
2022-07-07 17:28:01 <KipIngram   > I am interested in studying over how they implemented the vm.  Looks like that's in file embed.c.
2022-07-07 17:28:13 <KipIngram   > 267 lines.
2022-07-07 17:32:16 <KipIngram   > Looks pretty easy to suss out.  Different from how I did mine - I had C one-liners for the primitives in the same way, but I used gcc's "pointer to label" extension to make it run in a full-fledged way.  No switch statements or that sort of thing.
2022-07-07 17:32:50 <KipIngram   > Really the only difference between it and the later assembly ones was 1) the primitives were written in C and 2) important quantities were in variables instead of registers.
2022-07-07 17:33:23 <KipIngram   > But I don't think the way I did it can be done in "standard C."
2022-07-07 17:36:22 <KipIngram   > We should point this project out to vms14.  Maybe it could get him closer to actual Forth than he was managing.
2022-07-07 17:37:10 <KipIngram   > Anyway, I approve of its simplicity, and particular approve of it being able to recompile itself.
2022-07-07 17:38:54 <KipIngram   > Gah.  I haven't worked on mine in months.  I really need to get back to it.  :-|
2022-07-07 17:39:20 <KipIngram   > I seem to shove it along in big burtss, with lengthy periods of dallying in between.
2022-07-07 17:41:28 <KipIngram   > The recompile thing is my next really major goal, and I think I have a good plan for it.  I've just dodged diving into it, though, because I know it's going to be a fairly large amount of work.
2022-07-07 17:42:30 <KipIngram   > It means re-writing the primitives, using a new Forth assembly format.  I've *tried* to place actual Forth definitions above the nasm definition implementations, as comments, but that's bound to have some errors in it that I'll have to chase down.
2022-07-07 19:02:56 <Zarutian_HTC> 
ACTION sees KipIngrams mention of a Forth VM implemented in C

2022-07-07 19:03:29 <Zarutian_HTC> which reminds me I should dig out the fcpu32 vm implementation
2022-07-07 19:04:10 <Zarutian_HTC> which is pretty much a switch statement inside a loop
2022-07-07 19:05:31 <Zarutian_HTC> 16 direct primitives (0x0 - 0xF inclusive) anything above 0xF is a call to that address
2022-07-07 19:06:18 <Zarutian_HTC> memory is in a statically defined mutable array of uint32's
2022-07-07 19:09:30 <Zarutian_HTC> most basic io  is done with write() to stdout and reading the stdin in uncooked mode, raw with a check if there are bytes pending first
2022-07-07 19:19:10 <Zarutian_HTC> had not got quine_save functionality going yet though
2022-07-07 19:20:52 <Zarutian_HTC> what is that? prints or saves to a file the c source code needed to get this save instance going again
2022-07-07 19:21:54 <Zarutian_HTC> that is, the vm and its forth memory image is in on big c file