<whitequark[cis]>
the simulator plots signals, not expressions
<whitequark[cis]>
(this is very ordinary in HDL world; it only looks odd here because the simulator and the HDL are embedded in the same language)
<whitequark[cis]>
oh hey the bug you found was merged in yosys
<whitequark[cis]>
I can manually trigger a yowasp build (this is something i routinely do on important bugfixes; it's really easy because yowasp maintenance is nearly completely automated)
<mcc111[m]>
whitequark[cis]: cool
<mcc111[m]>
if i could bump to a version with that bugfix i would probably do so
<mcc111[m]>
so… to describe a thing i was doing, maybe with intent of being told "you're doing this wrong"
<mcc111[m]>
i want to create a compound expression
<mcc111[m]>
I think possibly I could be, like, defining five sub-signals here and composing them into the sixth signal, instead of building up a complex expression and submitting it to .comb all at once
<mcc111[m]>
as far as i know it's exactly as efficient either way
<whitequark[cis]>
I'm a bit confused here, how does this lead to the simulation error?
<mcc111[m]>
It doesn't, there is no relation at all
<whitequark[cis]>
oh
<whitequark[cis]>
oh I completely misunderstood the question
<mcc111[m]>
I mentioned it because you mentioned the upstream yosys bug and i mentioned I was worried about my compound expression here because I root it in that am.C(0)
<whitequark[cis]>
honestly, you should not be working around toolchain bugs all the time as I made it a point to have these just... fixed
<whitequark[cis]>
which I would normally do, but here charlotte did it first while i was sleeping
<whitequark[cis]>
in any case, this particular bug was control construct specific
<mcc111[m]>
right, but
<mcc111[m]>
this is why i'm interested in upgrading to the version with the fix :)
<whitequark[cis]>
any expressions should work well, yosys uses randomized testing to cover that
<whitequark[cis]>
whitequark[cis]: the build infrastructure also automatically updates the upstream yosys version and creates new branches for major yosys version, i'm quite proud of it
<whitequark[cis]>
for the most part it works completely autonomously, without requiring any manual intervention at all unless something goes wrong
<charlottia>
Are you adding with add_sync_process? Or otherwise talking about a clock?
pbsds has joined #amaranth-lang
<mcc111[m]>
So after simplifying my program and testing in the simulator I feel like I'm seeing different results on the simulator than I'm seeing in real life and I am seriously wondering if perhaps something is actually wrong with this device electrically or from a wiring perspective
<mcc111[m]>
due to the fact that, for example, even the LEDs I am not lighting look at least a little lit
<wehnelt[m]>
ah ha -- yes that's exactly what I'm using. What's the alternative?
<wehnelt[m]>
the alternative to add_sync_process I mean
<charlottia>
add_process
<whitequark[cis]>
mcc111: that FPGA has a pull-up active by default on all pins you don't explicitly use
<whitequark[cis]>
it's a high value (low current) pull up but modern LEDs can be visibly bright even with just that
<whitequark[cis]>
e.g. on the glasgow, the trans flag LEDs look half lit even when nothing is driving them
<whitequark[cis]>
which is convenient in the context, since most applets don't use those LEDs
<wehnelt[m]>
aaaand it works! thanks charlotte and catherine!
<mcc111[m]>
I have nine pins, which charlotte kindly set up for me based on reading a verilog file I haven't myself examined yet, four aled o bits which designate whether a row has a lit up led, one kled o bit which is always high for a reason i' not totally clear on, and four kled oe bits which designate whether a column has a lit up led
<charlottia>
fwiw, I noticed the Verilog we converted from explicitly floated the cathodes and so we reproduced that ...
<mcc111[m]>
should the kled "shared" o bit go off when nothing at all is lit?
<charlottia>
I haven't read the schematic closely enough to know if we actually must do that, or if it'd be fine to just ground them instead? It doesn't look obviously charlieplexed given the 4 + 4, but I don't know.
<whitequark[cis]>
hm
<whitequark[cis]>
I haven't looked at the schematic either
<charlottia>
(in other words, maybe that Verilog was more than a little cargo-culted)
<mcc111[m]>
Right is expected, left is actual. I am sweeping bottom to top, then right to left, and lighting each pixel or not. As long as on each pass I leave the top row unlit, I can light fine. But if I draw in the top row the bottom row looks all weird
<mcc111[m]>
the fact i'm iterating rows then columns rather than columns then rows makes it a little hard to tell that this is correct, but it appears to be correct.
<mcc111[m]>
i was really worried about like, on some particular cycle lighting up an aled but not a kled, or more than one aled or more than one kled. but that doesn't happen and these are in the order i expect.
<mcc111[m]>
what's surprising to me is that the top three rows are correct (aside from the varying degrees of half lit ness)
<mcc111[m]>
and like i said, when I altered the pattern i was printing so the top row was all blank, the bottom row stopped displaying wrong
<mcc111[m]>
i don't think i saw these kinds of problems when i was commanding the "default code" via spi from the microcontroller, but i was printing semirandom patterns at that time so i'm not sure i would have seen for sure
<charlottia>
ah
<charlottia>
.. actually nvm, I misread something.
<charlottia>
It might be worth slowing down a bit -- right now it looks like you move from one LED to the next every single cycle. (_aled_bits is slice(0, 2))
<mcc111[m]>
ok. i've actually already got both a "dim all" and a "dim certain rows" logic in there i turned off to make testing easier
<charlottia>
(that example, for instance, changes LED every 2^5th cycle, it looks like?)
<mcc111[m]>
oh really
<mcc111[m]>
that's quite a few samples
<charlottia>
I don't quite recall what you're clocking at, but it's probably the LEDs don't power on or off for long enough to look particularly clear
<mcc111[m]>
I don't need to turn off for any cycles between cycles, do i?
<charlottia>
So it makes sense that it's kinda weird all over the place
<mcc111[m]>
i men before led selects
<charlottia>
Nope
<charlottia>
Try adding a few bits (maybe 5 to be like the example) to the bottom of your counter, and then start taking _aled_bits and _kled_bits etc. from there.
<mcc111[m]>
charlotte, incredible!! every single day i have worked on this you have managed to give me better support on this board than the actual manufacturer gave me in six years of owning it
<mcc111[m]>
* in six combined years of
<mcc111[m]>
it works!! this is very exciting.
<charlottia>
!!!! Yaaaaaaay!! :3
<charlottia>
Super glad to see it :D
<wehnelt[m]>
Hmm is there a way to get the example I provided to provide output in a single clock?
<wehnelt[m]>
I got zero working by making everything combinatorial
<charlottia>
What's the exact behavior you're after? If you want the read port to show the data in the same cycle that the address registered by it, you'll need to make the read port comb (.read_port(domain="comb")).
<charlottia>
(But it's worth noting that async reads will likely disqualify the memory from using available block RAM on your target? Maybe! It'll probably get synthesized with gates.)
<wehnelt[m]>
I think I'm trying to create a module that abstracts over the functionality of a lookup table. I put something on the input, and a cycle later, I get the output
<wehnelt[m]>
where the lookup table is implemented with a read-only Memory
<charlottia>
Right! You should get that already, honestly; but maybe you're seeing it as two cycles?
<wehnelt[m]>
yeah -- I'm seeing two cycles
<charlottia>
Right! Because the memory's only actually seeing that new address the cycle after you've "issued" it.
<charlottia>
It then takes the memory one cycle to respond to that.
<charlottia>
If your m.d.sync += input_addr.eq(blah) is hit on cycle n, then the memory only actually can do anything about that on cycle n+1, meaning you only see the result and can use in your logic on cycle n+2.
<charlottia>
If the read port was async, then on cycle n+1 when the new address hits, the new data would be immediately available too.
<wehnelt[m]>
it's that _first_ part I don't understand
<wehnelt[m]>
oh wait
<wehnelt[m]>
oh.
<wehnelt[m]>
ok so this is totally expected behavior
<charlottia>
Yep!!
<wehnelt[m]>
once it's embedded in some larger thing
<wehnelt[m]>
it'll probably start to make more sense
<wehnelt[m]>
or rather it makes sense now
<wehnelt[m]>
but it's sort of off-by-one in the simulation
<charlottia>
I think so. If you wrote a little fake/stub Memory yourself, you'd see it quickly.
<charlottia>
Yeah?
<wehnelt[m]>
oofah. Ok. That makes sense
<wehnelt[m]>
thanks!
<charlottia>
Np!
<charlottia>
amphet
<charlottia>
(focus stolen, apologies!)
GenTooMan has joined #amaranth-lang
GenTooMan has quit [Ping timeout: 248 seconds]
GenTooMan has joined #amaranth-lang
Darius has quit [Ping timeout: 245 seconds]
Darius has joined #amaranth-lang
indy has quit [Ping timeout: 246 seconds]
indy_ has joined #amaranth-lang
indy_ is now known as indy
jess has quit []
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
<mcc111[m]>
Looking for advice— I have this problem where I'm constructing submodules, and some of those submodules take signals as constructor arguments. But some of the signals they're gonna watch are provided by the platform. So I can't create them until elaborate.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/epIYYdXAQDfOcMvGRRGKOYJk>)
<whitequark[cis]>
generally I advise against passing signals around as arguments, in favor of every module creating signals in its constructor, and then its parent module connecting it in elaborate
<whitequark[cis]>
connecting two wires is literally free
<whitequark[cis]>
it never has any impact on the resulting HDL because in the netlist, named wires are just aliases for the actual node
<mcc111[m]>
oh, that is interesting.
<whitequark[cis]>
the RFC #2 i'm working on is intended to make that even easier for complex buses/modules
<whitequark[cis]>
this also results in somewhat easier to read/use structure in waveform viewer
<whitequark[cis]>
yeah. though instead of actual_observe the name is typically the same
<mcc111[m]>
makes sense thanks
<mcc111[m]>
when i first started doing this i was really excited about how few signals i could create
<mcc111[m]>
like lots of "oh, instead of building this expression out of composed signals, i could construct essentially the ast for an expression programmatically!"
<mcc111[m]>
and then i realized that just made it really hard to debug in the simulator
<whitequark[cis]>
yes. constructing the AST is how it was originially portrayed in Migen
<whitequark[cis]>
and now I'm spending years of effort moving away from that model because it's kind of terrible
<mcc111[m]>
it's definitely fun
<mcc111[m]>
…which is, unfortunately, not an adequate, and sometimes an actively bad reason, to do things a certain way while programming
<whitequark[cis]>
re: LSB-first, you can always do Cat([0,1,0,1,1,0,1,0])
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #amaranth-lang
GenTooMan has quit [Excess Flood]
<mcc111[m]>
<whitequark[cis]> "there has been a PR for acceptin..." <- oh, that's a good idea
<mcc111[m]>
<whitequark[cis]> "re: LSB-first, you can always do..." <- OK. I think this solves my problem because I can build my own tools out of this
<whitequark[cis]>
it's not been accepted on a community design meeting
<mcc111[m]>
I think as long as the idea's being considered I'm satisfied for now
GenTooMan has joined #amaranth-lang
<galibert[m]>
I tend to do m.submodules.counter = counter = self.counter
<galibert[m]>
Catherine : it’s been refused or it just needs work?
<whitequark[cis]>
galibert[m]: the idea with the `elaborate` function is that it would not change the component being elaborated in any way; so you'd assign `self.counter` in `__init__`, and `m.submodules.counter = counter` in `elaborate`
<whitequark[cis]>
galibert[m]: it has been refused since it does not seem that it pulls its own weight in the introduced complexity of another implicit typecast
<whitequark[cis]>
we already have a lot of those and it's not the greatest
<galibert[m]>
I see. Dumbass python means you’d need counter = self.counter in elaborate
<galibert[m]>
There was no Counter() in my line :-)
<galibert[m]>
(I consider requiring self. pure stupidity. I know a lot of people disagree, it’s not that important in any case)
<whitequark[cis]>
you should probably treat decisions you disagree with more respect
<whitequark[cis]>
* disagree with with more respect
<whitequark[cis]>
explicit self isn't a matter of opinion in python; it is required for decorators to work well with the object moel
<whitequark[cis]>
s/moel/model/
<galibert[m]>
The only potentially interesting thing with the bytes conversion is to ensure a correct shape no matter how many zeroes are in there, which is I agree not enough to justify yet another conversion
<galibert[m]>
What are decorators exactly?
<whitequark[cis]>
```
<whitequark[cis]>
def foo(...)
<whitequark[cis]>
@something
<galibert[m]>
Ok, it’s something I need to read about, never learned them
<mcc111[m]>
galibert[m]: I feel like if someone is passing in a bytes structure, it's reasonable to assume they want a multiple-of-8 bits unless they specify otherwise, because the most useful application for this case is a large buffer
<whitequark[cis]>
galibert[m]: it really doesn't look good when you do not know some of the basic and pervasively used concepts in the language (Amaranth uses decorators a fair amount) yet call other decisions made in it "stupidity".
<mcc111[m]>
maybe the rfc already talks about this
<whitequark[cis]>
it's quite uncommon to want to stuff a constant byte sequence into a signal
<whitequark[cis]>
there's a bunch of things beginners want that only pop up in beginner code, because by the time you moved on to more complex projects you kind of stop wanting it
GenTooMan has quit [Ping timeout: 248 seconds]
<whitequark[cis]>
and a conversion from bytes seems like one of those
<mcc111[m]>
I could imagine wanting to stuff an 8-byte window from a longer constant into a signal
<whitequark[cis]>
that said, your proposal is actually more limited in scope, since the RFC I mentioned before would make x.eq(b"abc") legal, and yours would only make Const(b"abc") legal
<whitequark[cis]>
so it would have more chance to be accepted
<whitequark[cis]>
mcc111[m]: you could use `Array(b"abc")[index]`
<galibert[m]>
Except it’s probably not that useful in the first place
<whitequark[cis]>
it will result in exact same logic derived from it
<mcc111[m]>
whitequark[cis]: I think it would make much, much more sense to require wrapping in Const, because (1) this thing will probably not be so frequent that a shorthand is needed, and (2) this gives a ready opportunity to specify shape
<mcc111[m]>
whitequark[cis]: b"" is already accepted in that case (the constructor of amaranth.Array?)
<whitequark[cis]>
yes, any sequence type is accepted, and bytes is a sequence type
<mcc111[m]>
oh, interesting
<whitequark[cis]>
Array is a weird entity, it is a multiplexer that does not require its values to be Amaranth values
<whitequark[cis]>
so it's not like a long Mux chain, but rather it's codegen'd multiple times to cover every possible value
<whitequark[cis]>
which among other things lets you use it on LHS
<whitequark[cis]>
e.g. Array([sig1, sig2])[index].eq(1) is legal
GenTooMan has joined #amaranth-lang
<mcc111[m]>
whitequark[cis]: Does this create practical problems at elaborate/compile time if, for example, a constant array is megabytes in size?
<mcc111[m]>
I strongly suspect if I've made a megabytes-size array i'm doing something wrong, just curious
<galibert[m]>
Catherine: I didn’t see the python case from up close, but I was there when a number of languages decided that programmers having to know if a variable name was a object member, a parameter or a global was just too hard. Which justified things like self., m_mumble or even code styles requiring this-> on every member access in C++
<galibert[m]>
mcc: megabytes means Memory, and Memory initialisation is more flexible
<whitequark[cis]>
mcc111: it does; but also, any FPGA you can afford won't have megabyes of memory you can use
<galibert[m]>
I’m pretty sure self. happened way before decorators
<whitequark[cis]>
like, unless you're willing to buy a Xilinx Ultrascale device, I don't think there is any device which lets you stuff a megabyte of data into it
<galibert[m]>
IIRC the cyclone v tops at around half a megabyte
<mcc111[m]>
It is my sense that consensus in the language design space is moving toward explicit self on member access. Rust uses it, Swift uses it. Go uses the python "first argument" convention.
<whitequark[cis]>
galibert: so? explicit self is still incredibly useful for metaprogramming use cases, as shown by decorators (something that is incredibly painful in Ruby due to implicit self)
<mcc111[m]>
So uh segueway from talking about naming
<mcc111[m]>
Something I find myself doing in Amaranth is I name all object members which are _not_ signals with a trailing underscore
<mcc111[m]>
Starting to consider doing this for variable names also
<mcc111[m]>
How… absurd does this sound to you? It's un-pythonic but not _very_ un-pythonic
<mcc111[m]>
s/trailing/leading/
<mcc111[m]>
I'm just finding it's deeply important to not mix up signals and non-signals
<galibert[m]>
So I really don’t like that members code source is way noisier that bare functions when most of everything should be a member. Like you I do way more work in other people’s code than writing new one, and that makes me dislike avoidable noise
<whitequark[cis]>
galibert[m]: knock off calling features in a language you don't understand very well "stupidity". this makes me want to not take your views on language design with any degree of seriousness. am I clear?
<galibert[m]>
mcc: rfc #2 should eventually make Elaboratable “prototypes” look different than other members, which should be very nice
<galibert[m]>
Catherine: what you’re citing deliberately didn’t go further than “dislike”. I have no interest in annoying you.
<whitequark[cis]>
as long as we're on the same page here, great
<whitequark[cis]>
mcc111: the convention used in core Amaranth code is the more common 'pythonic' one where an underscore is used for private members, and a double underscore is used for private members where namespace collision is important to avoid, like in mixins
<whitequark[cis]>
signals are distinguished from non-signal members in the documentation, or by looking at the constructor
<galibert[m]>
I think we are, just needed a little more calibration. Fwiw I tend to consider bashing decisions acceptable while bashing people off-limits. You have stricter limits than that, I’m ok with that.
<whitequark[cis]>
there are certain cases where I accept bashing decisions, but this requires knowing the language really well--"you have implemented it" degree of knowing it well
<whitequark[cis]>
however knowing a language that well tends to make you not want to bash any decisions in it anyway
<whitequark[cis]>
so it's mostly a moot point
<whitequark[cis]>
it is very rare that a decision in a language is truly bad rather than a result of tradeoffs you don't like
<galibert[m]>
Hmm, there are things I really dislike in C++ while knowing the language… rather well
<whitequark[cis]>
yeah, same
GenTooMan has quit [Ping timeout: 240 seconds]
<whitequark[cis]>
though my personal stance on C++ is that the entire thing has been a mistake and I might as well calm down talking about individual parts of it
<galibert[m]>
Huhuhu
<whitequark[cis]>
this doesn't prevent me from discussing the tradeoffs involved, though I try to avoid that because I want to spend my life on something I actually like
<whitequark[cis]>
mcc111: with rfc #2, the idea is that there will be an automated check that a module conforms to its signature, which includes ensuring that everything declared as a port is a Signal or at least a Const (for outputs) of some sort
<galibert[m]>
While I quite like it except for the parts I don’t, which is probably not that good an indicator for my taste
<whitequark[cis]>
mcc111: sort of like .mli files in ocaml, I guess
<whitequark[cis]>
galibert: I find it that language design discussions are much more fruitful if the tradeoffs that go into making decisions are discussed explicitly beforehand, and all participants share the values, or at least agree to pretend to share values for the time being
<whitequark[cis]>
for example, Ruby made a lot of choices based on some abstract ideas of conciseness and beauty, not unlike Perl
<whitequark[cis]>
the decisions that were made are consistent and reasonable within that framework, even if understanding that framework was what led me to quit Ruby development entirely because I just couldn't justify contributing to it
<galibert[m]>
Sure. I tend to be more sanguine about decisions that are… I’m not sure how to put it, more philosophical than practical?
<whitequark[cis]>
but I can pretend to like the things that resulted in a 11,000 line parse.y file in order to discuss it, or at least to implement it
<galibert[m]>
Like in C++ requiring cast to void * or putting Class:: in front of member names to get pointers
<whitequark[cis]>
all right, I'm considering finishing RFC#2 work this weekend
<whitequark[cis]>
would be the first time I work on a weekend in months, but I'm kind of motivated to do this
<whitequark[cis]>
have you seen my latest push to a branch?
<mcc111[m]>
I don't think I can answer that question. The one thing I know, from working with the SAMD, is that they are doing a magpie thing of reusing whole components from different places and not fully testing them
<whitequark[cis]>
I think releasing a schematic with an IC package that has no pin numbers is below my bar for basic competence
<whitequark[cis]>
this is a truly terrible schematic
<whitequark[cis]>
you're having trouble reading it because it is bad
<mcc111[m]>
Okay. That's good
<mcc111[m]>
Or… bad.
<mcc111[m]>
It's reassuring.
<whitequark[cis]>
IOB_nn[AB] are the Lattice internal pin namings
<whitequark[cis]>
this takes care of inverting the buttons so that the level you get is the logical level (1 = pressed, 0 = not pressed)
<whitequark[cis]>
and configures a pullup
<whitequark[cis]>
normally you would have a pullup on the board, since the FPGA-internal one is somewhat weak
<whitequark[cis]>
and you need a minimum current to pass through a button when it closes for it to operate reliably
<mcc111[m]>
Okay
<whitequark[cis]>
(this is not very widely known, but you should let a button draw at least a milliamp or two, because even though you can have it draw a few microamps, which will trigger the sensitive CMOS input buffer, it will not break the oxide layer that normally forms on the button; https://en.wikipedia.org/wiki/Wetting_current)
<mcc111[m]>
I don't know which thing you had me change that fixed it
<mcc111[m]>
But that fixed it
<whitequark[cis]>
(it's really fascinating how even the absolute simplest, most basic, beginner level components like "tact buttons" have opaque and difficult to identify failure modes)
<zyp[m]>
you just gave me a case of Baader-Meinhof
<mcc111[m]>
Okay I am very almost to feature complete on the demo I was trying to make :O
<mcc111[m]>
I think tomorrow I am going to try SPI
<mcc111[m]>
So I can have the SAMD make audio
<zyp[m]>
I recently did a board with a TIC12400, which is this fancy SPI input buffer thing, with configurable wetting and cleaning currents
<whitequark[cis]>
mcc111: nice!
<whitequark[cis]>
zyp: oh fascinating
<mcc111[m]>
There are at least 3 frustrating things about this board but possibly the worst is that uploading a build fails roughly 50% of the time
<mcc111[m]>
When it fails the only way out is to double-tap the reset button, an operation that itself only works about 70% of the time, and the only way to tell if it worked is to look at the programmer LED, too bright to look at directly, so I kinda shield my hand over it and look at the reflections on the USB port
<zyp[m]>
put a piece of tape over it
<whitequark[cis]>
mcc111: do you want me to buy you like a real board?
<whitequark[cis]>
or at least one that's less like this
<mcc111[m]>
(not clear if this comes with a screen)
<mcc111[m]>
however, there will be the regular "shipping from china to ontario" time
<mcc111[m]>
is there a different board you think i should have bought instead?
<whitequark[cis]>
mcc111[m]: it comes with a screen
<mcc111[m]>
the thing I like about the Doppler, and the thing that would make me consider continuing to use it even if i had a better board, is that it does have the FPGA in conjunction with a microcontroller connected by SPI, which is neat and I don't know how common it is (although it definitely makes it less useful that some features of the SAMD don't work due to flaws in their arduino sdk package)
<whitequark[cis]>
the screen is like... imagine a 2007 netbook? it's like that
<whitequark[cis]>
but it's also like 30 bucks
<mcc111[m]>
* the thing I like about the Doppler, and the thing that would make me consider continuing to use it for some things even if i had a better board, is that it does have the FPGA in conjunction with a microcontroller connected by SPI, which is neat and I don't know how common it is (although it definitely makes it less useful that some features of the SAMD don't work due to flaws in their arduino sdk package)
<mcc111[m]>
cute
<whitequark[cis]>
mcc111[m]: you could buy an FPGA board (that's good), an MCU board (that's good), and use 5 wires to achieve the same
<whitequark[cis]>
MCU boards got literally dirt cheap at this point, FPGA boards got pretty cheap too
<mcc111[m]>
hm, well ok that's a point
<mcc111[m]>
they got expensive during th epandemic for a bit but now they seem to be cheap again
<whitequark[cis]>
yeah we seem to have actually survived the semiconductor shortage
<whitequark[cis]>
which wasn't a given
<whitequark[cis]>
I've known some insiders who were worried we won't, as a civilization, get out of it alive
<mcc111[m]>
i think i will let the $30 screen board arrive, wait and see when / if Analogue Pocket ships my unit, and see what I feel like I'm missing
<whitequark[cis]>
there are some FPGAs with integrated MCUs. I strongly suggest avoiding them
<mcc111[m]>
ok
<whitequark[cis]>
almost no vendor does this in a way that is remotely reasonable, for some reason
<whitequark[cis]>
both the FPGA and the MCU end up being extra cursed
<mcc111[m]>
i feel like i used a good one around 2007 briefly, but I wasn't responsible for working with the fpga part.
<mcc111[m]>
somebody else did that.
<whitequark[cis]>
which vendor was it?
<whitequark[cis]>
Altera?
<mcc111[m]>
I don't… remember. I just remember we used a xylinx programmer chain
<mcc111[m]>
slash tools
<whitequark[cis]>
okay, then it was Xilinx
<mcc111[m]>
So here's a question. I know I can get a big FPGA and do a softcore in it
<mcc111[m]>
if i assume that an fpga softcore won't work as well as a real mcu am i thinking about this wrong
<zyp[m]>
zynq weren't out in 2007, was it?
<whitequark[cis]>
I don't think it was
<zyp[m]>
google says introduced in 2011
<whitequark[cis]>
mcc111[m]: > <@mcc111:matrix.org> So here's a question. I know I can get a big FPGA and do a softcore in it
<whitequark[cis]>
> if i assume that an fpga softcore won't work as well as a real mcu am i thinking about this wrong
<whitequark[cis]>
a softcore in an FPGA is the preferred option for an FPGA+MCU combination
<whitequark[cis]>
because you control the entire thing and you don't use the cursed combo devices
<whitequark[cis]>
it will be somewhat slow. in particular the UltraPlus series FPGA you have is extremely slow
<zyp[m]>
I for one would love to have a reasonable cortex-m mcu with a reasonable FPGA fabric that allows me to add some custom memory mapped peripherals
<whitequark[cis]>
I mean I can just give you cortex-m0 sources
<whitequark[cis]>
I brought it up with Yosys. I still have the build tree
<zyp[m]>
yeah, but I want the performance of a hard core
<whitequark[cis]>
ah
<zyp[m]>
effectively what I'd like is not a fpga project with a cpu, but a mcu project with a custom peripheral
<whitequark[cis]>
quicklogic is supposed to be like that
<zyp[m]>
yeah, but then you end up spending the entire fabric making a simple usb core, at least with their demo board
<whitequark[cis]>
too bad their fabric is slower than lattice's ultraplus, and their "FOSS first" toolchain is so bad they secretly have another proprietary toolchain they give to every customer that complains that the FOSS one does not work well
<whitequark[cis]>
* too bad their fabric is slower than lattice's ultraplus, and their "FOSS only" public toolchain is so bad they secretly have another proprietary toolchain they give to every customer that complains that the FOSS one does not work well
<mcc111[m]>
Anyway, I'm definitely interested in recommendations for "a pretty good fpga"
<mcc111[m]>
And would not mind getting a decent MCU to go with it (probably riscv out of sheer cussedness)
<mcc111[m]>
But I'm unlikely to spend more than $100 on this right now due to a lack of, like, actual applications for the thing