<kc5tja>
ZipCPU: Apologies -- I'm just wrapping up at work now, will be home as quickly as traffic will allow me. Estimated 30ish minutes. Apologies for delays; fighting severe API outages at work.
<kc5tja>
Be back shortly; driving now.
kc5tja has quit [Client Quit]
digshadow has quit [Ping timeout: 268 seconds]
<ZipCPU>
Evening, kc5tja!
kc5tja has joined #yosys
<kc5tja>
Back from commuting.
<ZipCPU>
Welcome back!
<ZipCPU>
I haven't looked at your code since ... Monday I think it was. Have you uploaded everything, so that the repo is current?
<kc5tja>
Sorry about the delays. This past couple of weeks has been a disaster for me.
<ZipCPU>
They always are. ;)
<kc5tja>
Hang on, and I'll upload what I have. It's not too different, but it takes your Monday e-mail into account. Just a second.
<kc5tja>
OK, the files should be uploaded to the repository.
<ZipCPU>
Got it
<kc5tja>
After making the change to a saturated counter, the induction waveform changed just so slightly, but it looks like it's failing the same assertion for the same reason.
<ZipCPU>
SIA ... tilelink?
<kc5tja>
Yes.
<ZipCPU>
Running SymbiYosys now
<kc5tja>
:118
<kc5tja>
err
<ZipCPU>
Assert failed in sia_tilelink: properties.vf: 122
<kc5tja>
Yes.
<ZipCPU>
Ok, let me pull up the trace and properties.vf
<ZipCPU>
Fascinating how nothing changes until the end, save only z_past_valid
<ZipCPU>
Remember that pattern: it means something
<ZipCPU>
So, here's what that pattern tells you: You are missing an assertion, two or three.
<ZipCPU>
Did you see the tweet from the other day outlining the three places where you can have an induction bug?
<ZipCPU>
So, looking over i_a_valid, its getting deasserted without o_a_ready ever going high. Is this a valid behavior?
<kc5tja>
That's literally *always* been the case for induction. I've never had an inductive trace that wasn't more than a few cycles of chnage at the very end.
<kc5tja>
No.
<ZipCPU>
i_a_valid is an input, so let's make some assumptions about it
<kc5tja>
It's allowed by the TileLink spec.
<ZipCPU>
It's allowed?
<kc5tja>
Take one master and one slave (M and S).
<kc5tja>
Well, two slaves: S1 and S2.
<kc5tja>
At time t0, M might present an address for S1, but S1 might not be ready for it. So M will need to wait for S1 to become ready before it can make progress.
<ZipCPU>
Ok, so look over your trace then. Something in the first couple of timesteps is in error.
<kc5tja>
However, is a higher priority message needs to be transmitted, M can present a bus transaction for S2 during that cycle.
<kc5tja>
So, from S1's point of view, M can assert valid, and then negate it again at any time (assuming the slave is not driving its ready output).
<ZipCPU>
Ok, let's look at o_d_valid. Is that going high in response to a request from somewhere?
<kc5tja>
That's being driven high from the state machine. The state machine is being brought up as if a master had written to the TXOUT register (slave_txout is asserted at timestep 0). Once that state completes, it will advance to the slave_ack state, which drives o_d_valid.
<ZipCPU>
So the induction engine is starting mid transaction then?
<kc5tja>
Thing is, in this trace, no bus transaction exists; it's just the completely random state that Yosys came up with.
<kc5tja>
Yes.
<kc5tja>
And I'm not sure how to constrain that.
<ZipCPU>
How can you tell that there's no existing transaction?
<ZipCPU>
Help me out here, and I'll show you how to constrain this ...
<kc5tja>
It should be in slave_ready state.
<kc5tja>
Basically, after reset, it should sit in slave_ready state until a transaction comes in on the A-channel.
<ZipCPU>
Sure ... but if slave_ready is false, what should be true?
<kc5tja>
Once a message has been received there requesting a get or put operation, it will advance to another state depending on what's addressed and the nature of the transfer.
<kc5tja>
Only one slave_* signal should be true at any given time. At no time can none be true.
<ZipCPU>
Ahh ... okay, can you then assert(|{slave_*}); ? (Pardon the poor verilog, but I hope you get the idea)
<ZipCPU>
Hmm, no, that's not quite it.
<kc5tja>
Line 42 already does that, in a more verbose way.
<ZipCPU>
Ok, so ... it says all_states == 3'b001, that's valid then
<kc5tja>
Right.
<kc5tja>
I think what I need is some way to say that the state progression can only go 3'b100 -> 3'b010 -> 3'b100 or 3'b100 -> 3'b001 -> 3'b010 -> 3'b100, in those orders, but with arbitrary delays in between them.
<ZipCPU>
That's just about given, I'm more worried about constraining the other signals that must be true when all_states == some value
<kc5tja>
(since state changes are gated by the various ready/valid signals)
<ZipCPU>
For example, if (all_states == 3'b001), do you constrain txn_opcode to be `D_OP_ACK?
<ZipCPU>
Or ... what would happen if you are in state 3'b001, and is_put becomes true? Will that ever happen?
<kc5tja>
That would be line 117, yes?
<ZipCPU>
Actually, I was looking at sia_tilelink.v:98
<kc5tja>
No, that cannot happen because o_a_ready will be negated. o_a_ready is only ever true when state is 3'b100.
<ZipCPU>
Ok, that's what I'm looking for.
<ZipCPU>
So you want to say that, if (o_a_ready) assert(all_states == 3'b100); ?
<ZipCPU>
Let's back up a moment though
<ZipCPU>
Remember how the tools treat an assertion during induction
<ZipCPU>
Your induction trace has roughly 200 steps to it.
<ZipCPU>
During the first 199 of those steps, the induction engine will treat any assertions as though they were assumptions
<ZipCPU>
So, the more you can assert, the more you are guaranteeing that your design will stay within bounds.
<ZipCPU>
Hence, if (o_a_ready) assert(all_states == 3'b100); will be treated as an assumption for the first 199 clock cycles.
<kc5tja>
OK, I get that, but theory and practice are only theoretically related.
<kc5tja>
How do I put that into practice in a meaningful way?
<ZipCPU>
What do you mean?
<ZipCPU>
Ahh ...
<ZipCPU>
Ok
<ZipCPU>
In this case, you look at your trace. You discover what's wrong on the left hand side. Something shouldn't look right. You then create an assertion that the "doesn't look right" state will never happen.
<ZipCPU>
You then need to run both basecase and induction step again (SymbiYosys will do this automatically when you run it)
<ZipCPU>
If you over constrain things, your design may fail because of this new assertion
<ZipCPU>
If you do it right, the design will pass, and you'll find another bug in the left hand side
<ZipCPU>
So then you create another assertion, and so on and so forth until you get to a bug in the last clock of the trace
<ZipCPU>
At that point, you may have a bug in your code and not just in your properties (i.e. a missing property)
<kc5tja>
So I should just straight-up ignore anything from timesteps 1..199 and just focus on timestep 0? That seems overly simplistic.
<ZipCPU>
No
<ZipCPU>
If there's a bug in timesteps 1...199, then you need one or more additional assertions
<ZipCPU>
You don't ignore things, you constrain them further
<ZipCPU>
That's why I was asking you, what do you see "wrong" in the trace on clocks 1..199
<kc5tja>
I think another problem I have is, until I see a reset signal being asserted, I (as a human) assume the state to be totally random.
<kc5tja>
In the induction traces, I never see a reset. So, how do I distinguish what are don't-care states from states that are legitimately erroneous?
<ZipCPU>
Well, okay, is that how you'd like to constrain things?
<ZipCPU>
We can do that if you'd like.
<kc5tja>
Well, why *wouldn't* I do it that way? What are the tradeoffs?
<ZipCPU>
I use initial statements. The tradeoffs are a war between ASICs and FPGAs. ASICs don't honor resets.
<ZipCPU>
Sorry, other way around
<kc5tja>
Apologies if I seem daft -- it seems like I have this world-view and Yosys has another world-view, and I'm just trying to reconcile them.
<ZipCPU>
FPGA's don't need resets. ASICs don't honor initial statements.
<ZipCPU>
No, that's not it at all.
<ZipCPU>
Yosys is generic to your world view
<ZipCPU>
I have the other world view
<ZipCPU>
So you and I are going through a world view difference between us, but the tools are agnostic
<ZipCPU>
It's not a problem, I just need to recalibrate what I'm telling you.
* kc5tja
nods
<ZipCPU>
So, as you've described things, your design will start with the reset high.
<ZipCPU>
You don't care about whatever happens before that reset, so let's start the design with the reset high on the first clock.
<ZipCPU>
always @(*) if (!f_past_valid) assume(i_reset);
<ZipCPU>
You could also do: initial assume(i_reset);
<ZipCPU>
But .... the second form has problems in a multiclock environment.
<ZipCPU>
Let's see ... how would you constrain the resets next ...
<kc5tja>
Tries (*) instead of (posedge i_clk)...
<ZipCPU>
if ((f_past_valid)&&(!i_reset)) assert(whatever_is_reset_dependent);
<ZipCPU>
Do you know the difference between @(*) and (posedge i_clk) for assertions?
<kc5tja>
(*) assertions hold for all time, and posedge assertions are evaluated on clock transitions.
<ZipCPU>
There's more to it
<ZipCPU>
posedge assertions are the only ones that can handle $past
<ZipCPU>
... $stable, $rose, $fell, or even $chanaged
<ZipCPU>
$changed
<ZipCPU>
@(*) is timeless from that standpoint
<kc5tja>
right.
<ZipCPU>
I like to assert anything that's timeless with @(*). It doesn't always work ... but that's my preference.
<ZipCPU>
The problem in your case with: if ((f_past_valid)&&(!i_reset)) is ... that's not appropriate for a synchronous reset.
<ZipCPU>
Your reset dependent logic will depend upon $past(i_reset) when you measure it
<ZipCPU>
But if i_reset == !f_past_valid ...
<kc5tja>
Right, all that I understand.
<ZipCPU>
You should be able to just test: if (f_past_valid) to test if your design has already seen a reset
<kc5tja>
:35
<ZipCPU>
:35 ... which file?
<kc5tja>
Sorry, my mouse pointer keeps scooching over into the IRC window.
<ZipCPU>
Lol
<ZipCPU>
You might want to test: if ((f_past_valid)&&(!$past(i_reset)) to test non-reset logic
<ZipCPU>
Reset logic you should be able to test with: if ((f_past_valid)&&((!$past(f_past_valid))||($past(i_reset)))
<kc5tja>
uugh, OK, this is getting to be very cumbersome.
<ZipCPU>
How so?
<kc5tja>
The mental load is starting to get pretty high.
<ZipCPU>
How so?
<kc5tja>
I can't even articulate.
<ZipCPU>
Then let me just encourage you. You'll get it. It's just a new way of thinking.
<kc5tja>
It's very incompatible with my way of thinking so far.
<kc5tja>
So, I have this in the properties now: always @(*) if(!f_past_valid) assume(i_reset);
<ZipCPU>
Good
<kc5tja>
That should be sufficient to reset the system, yes?
<kc5tja>
But the induction is still failing in the same way.
<ZipCPU>
Yes ... on the very first clock tick
<ZipCPU>
Yes .... we haven't gotten to fixing that yet.
<ZipCPU>
You still need an assertion that your design will never get into any illegal states.
<kc5tja>
In that case, nothing else looks out of order on the left-hand side of the trace.
<ZipCPU>
Nothing else? You mean only the lack of reset was out of order? That doesn't make much sense.
<ZipCPU>
There's more than just the missing reset going on.
<ZipCPU>
We were tracking on to that a bit ago.
<ZipCPU>
Making lots of changes?
<ZipCPU>
... or rather, are you making progress?
<kc5tja>
I'm pouring over my code and the trace.
<ZipCPU>
Does the trace look any better now?
<ZipCPU>
... or perhaps I should ask, is it still stuck at the same problem?
<kc5tja>
Still stuck. The o_d_opcode looks like it should be 0; but I'm baffled why it's 3'b101 because I *set* it to 3'b000 in the .v file.
<kc5tja>
But, that might be what you're referring to; it's only set if a proper bus transaction happens.
<kc5tja>
If we start up mid-transaction, then I might have to assert that the opcode is 3'b000 because we "assume" that the transaction happened earlier.
<kc5tja>
Is that right?
<ZipCPU>
Yes! Exactly!
digshadow has joined #yosys
digshadow has quit [Client Quit]
<kc5tja>
Oh dear, sby is working hard. Seconds between time steps.
<kc5tja>
OK, that passed both bmc and induction.
<ZipCPU>
Yaaayyy!!
<kc5tja>
OK, so I think going forward, it'll be in my best interest to break out composite asserts into individual asserts.
<kc5tja>
OK, yeah, I would probably just end up crying when faced with the task of proving the AFIFO. Heh. You're definitely a lot more disciplined than I am there.
<kc5tja>
Not sure disciplined is the right word.
<ZipCPU>
Not sure which was harder---building it first or proving it
<kc5tja>
Though, one question I have is, what if you can't gray-code the values going cross-domain?
<kc5tja>
E.g., what if they're not addresses? Or, if they are, they're not guaranteed to increment monotonically?
<ZipCPU>
Ahh ... okay, there is another approach.
<kc5tja>
I'm just curious. This isn't anything related to what I'm working on.
<ZipCPU>
You pass a token back and forth between clock domains. When the "sender" owns the token, he can change the value. Then he passes the token to the receiver. When the receiver holds the token, he can read the value. Then he passes it back to the sender.
<ZipCPU>
Only the sender can hold on to the token.
<ZipCPU>
The token itself is just a one-bit value.
<ZipCPU>
Sometimes I split the token exchange into two bits. The sender sends a REQUEST. When the receiver gets it, the receiver sends an ACK.
<ZipCPU>
When the sender clears the REQUEST line, the receiver clears the ACK line.
<ZipCPU>
When the sender sees that the ACK line is clear, he can send another word of data.
<ZipCPU>
This is more cumbersome and a lot slower than the gray code, but should work.
* ZipCPU
was implementing such a coding when building his own AFIFO first, before finding Cliff's
<kc5tja>
OK, so 4-phase asynchronous bus semantics then. A la 68000.
<ZipCPU>
Wouldn't know about the 68k. I sort of came up with this on my own.
* ZipCPU
looks around sheepishly for any patent trolls lurking outside
<kc5tja>
It's also used in a kind of 6-phase form in the GPIB bus too.
<ZipCPU>
See ... once you know how to do the async FIFO, a lot of things become possible. You can adjust it to your needs as well.
<ZipCPU>
For example, I have an ASYNC FIFO that feeds a video controller, but I've modified it to report its fill level
<ZipCPU>
I've also thought about using an ASYNC FIFO to cross clock domains with bus requests
<ZipCPU>
In that case, the FIFO needs four pointers, not just two.
<ZipCPU>
Two for read and write on the request side, and another two for the response/acknowledgement side.
<kc5tja>
Or two FIFOs: one for each direction of signaling.
<ZipCPU>
You could .... but their fill levels need to be tied together.
* kc5tja
nods
<ZipCPU>
You can't ever allow both to fill, especially if the ack side could end up getting stalled while more acks come in
<kc5tja>
OK, now that I got this code to pass induction, now I have to re-acquaint myself with what it actually does versus what I think it ought to do.
<ZipCPU>
Heheh ... Glad to see you on your way (again)
<ZipCPU>
Yes! (Personal note:) Just managed to build and prove a simple 1-clock AXI-lite slave.
<kc5tja>
Hmm, pushing a car doesn't mean the engine's running.
<kc5tja>
kkkkjjk
<kc5tja>
doggone it.
<ZipCPU>
kc5tja: When we started, you didn't have the frame yet. You are getting further along
<ZipCPU>
You like vi, huh?
<kc5tja>
I live in vi.
<ZipCPU>
You and me both.
<ZipCPU>
It's not that I don't care for emacs at all, it's just that I already like my O/S. :P
<kc5tja>
I've tried to learn emacs no less than six times.
<kc5tja>
I just can't do it.
rohitksingh has quit [Ping timeout: 252 seconds]
<kc5tja>
The mental model of its command structure is just so fundamentally incompatible with how I think an editor should behave that it's just not possible for me to learn.
<kc5tja>
Fun fact though -- my very first text editor was MicroEMACS on AmigaOS.
<awygle>
Emacs hurts my joints
<kc5tja>
But once I discovered Vim (which was originally developed on and for the Amiga!), I never looked back. It was just so smooth and efficient to use, I could work with text at the speed of thought.
<awygle>
Modifier keys are the enemy
<ZipCPU>
I can't remember if my first editor was ted or qx
<ZipCPU>
It was on a hard-copy terminal
<kc5tja>
There's that too -- these days, I now suffer from arthritis in my pinkie fingers, and am SHIFT-/CTRL-impaired.
<ZipCPU>
... if you can remember back that far
<kc5tja>
I can. VAX 11/780 printer terminal.
<ZipCPU>
VI uses that escape key heavily ...
<kc5tja>
I learned to program Pascal on those.
<kc5tja>
Yes, but you don't hold the escape key down while chording other keys, so it's easier on the joint.s
<kc5tja>
An attentive listener will be able to hear my right-hand pinkie crack every time I hit the shift, ctrl, or alt key with it. :(
<kc5tja>
and, yes, it hurts.
<ZipCPU>
:(
<ZipCPU>
Looks like I'll be in your neck of the woods again in a couple of months
<kc5tja>
ZipCPU: I don't know if you have any recommendations beyond "write good comments" yet, but I'd love to know more about how you keep yourself organized when using FV in your designs.
<ZipCPU>
Really? How so.
<kc5tja>
Consider: I have what I think is an SIA tilelink interface, but I don't really know yet in what condition it was left in when I went away from it.
<ZipCPU>
Ahh ... you spend week(s) at a time between coding sessions, and then struggle to know where you left off?
<kc5tja>
I've now gotten it to pass induction, but now I have to kind of reverse-engineer what I wrote (despite the comments in the properties file) to regain my internal state.
<kc5tja>
Yes; unlike a conventional programming language, Verilog is not at all conducive to straight-ahead code reading.
<ZipCPU>
Okay, so here's something that helps: Blogging. :P
<kc5tja>
Next to no time for that.
<kc5tja>
Correction.
<ZipCPU>
If you compare my articles documenting code, vs the code that isn't written about, there's a clear difference between the internal organization.
<kc5tja>
Next to no *bandwidth* for that.
<ZipCPU>
So that helps.
<kc5tja>
Yeah, it has a more or less literate programming feel to them.
<ZipCPU>
So I tend to organize my formal properties as: f_past_valid, assumptions about inputs, any property description files (i.e. bus interface files), the "Contract" describing the module, and then any assertions necessary to pass induction followed by any cover statements.
<ZipCPU>
Sometimes I'll even place "careless assumptions" at the bottom. (Careless assumptions will render the proof incomplete, but may help you bit off one piece of the problem at a time.)
<ZipCPU>
My problem is, when working with induction, I tend to add a whole bunch of cats and dogs assertions that have little order, rhyme, or reason to them. They just work.
<ZipCPU>
Cleaning those up tapes a bit of work
<ZipCPU>
I tend to only do that clean-up work when blogging.
<kc5tja>
Thank you again for your help. I'm half-way tempted to list you as a co-designer for the Kestrel at this point. :)
<ZipCPU>
:D
<kc5tja>
I should let you get some zzz's. It's close to midnight there, IIRC.
<ZipCPU>
While I'm human and I love recognition, the Kestrel is all you. You can list me in the acknowledgements though.
<ZipCPU>
Yeah, it's later here, but I did just finish building a "better" AXI slave, and I'm kind of excited by it.
<ZipCPU>
It only took about 30-60 minutes or so to do, and the proof passes as well. That's pretty nice.
<ZipCPU>
Key differences between my example and Xilinx's demo? 1) This one works (Xilinx's was broken), 2) All of the "registers" within this one are kept in a block RAM memory, and 3) This one allows a full bandwidth link, with one transaction per clock.
<kc5tja>
Congrats. :)
<ZipCPU>
A fun project, keeps me on my toes. I'll need to blog about it, once I can get someone to verify it actually works in hardware.
<kc5tja>
Yep. All my TileLink slaves are only half-bandwidth. They are either ready for data, or sending an acknowledgement, never both at the same time.
<kc5tja>
"Make it work. Then make it right. Then make it fast."
<ZipCPU>
I think I have all of the above at this point.
<ZipCPU>
Although .... it's quite generic, so it may not meet all users needs.
<kc5tja>
OOh, here's something I need to chat more with you about in the future.
<ZipCPU>
What's that?
<kc5tja>
I plan on re-using some elements of the SIA to make a RS-232-to-TileLink master interface (and, eventually, a slave interface as well).
<ZipCPU>
Ok
<kc5tja>
My purposes are different from yours, but the end result is the same, I think.
<kc5tja>
I need to serialize TileLink messages over a RS-232 link.
<kc5tja>
My question is, what do you do to ensure a reliable transmission?
<ZipCPU>
You've decided to tickle your peripherals before putting your CPU in place?
<ZipCPU>
Oohh ... reliable transmission ... ahm ... I don't do anything to ensure a reliable transmission.
<kc5tja>
My experience using FTDI chips (on Arduino Uno boards, to be specific) are that they are grossly unreliable at relatively high baud rates.
<ZipCPU>
I've run at 4Mbps reliably on one board, but only 1Mbps on another--same FTDI chip too.
<ZipCPU>
I think if you want *REALLY* high speed with FTDI, you should abandon UART
<kc5tja>
I was getting framing errors at 57600 bps.
<ZipCPU>
Really? At 57600?
<kc5tja>
Basically, I'd send 256 bytes, and only receive 250 to 251.
<kc5tja>
Yes.
<ZipCPU>
Are you sure you aren't struggling with some other problem?
<kc5tja>
This was on an Arduino Uno board, not the FPGA.
<kc5tja>
But that experience was what taught me the value of CRC checks and packet framing.
<ZipCPU>
I've got a design that uses CRC checks and framing, but ... that's a high-speed comms link between two boards.
<ZipCPU>
As with many of my projects, that ones in a perpetual state of disarray.
<kc5tja>
My goal with the FPGA is to drive the serial link at 115200.
<kc5tja>
Heh
<ZipCPU>
1Mbps is reasonable.
<ZipCPU>
My high speed comms-link was designed to run at about 300Mbps
<ZipCPU>
That would be the link speed.
<kc5tja>
FTDI drivers/chips only expose certain bit rates though.
<ZipCPU>
Yes.
<kc5tja>
The FTDI-based boards we have at work expose only 9600, 38400, and 115200 bps.
<ZipCPU>
They expose 1Mbps, 2Mbps, and 4Mbps
<kc5tja>
(which seems strange to me)
<ZipCPU>
I think they even go up to 12, but I've never run them that fast.
<ZipCPU>
Are you running on Linux?
<kc5tja>
Yes
<kc5tja>
FT2232
<ZipCPU>
You should have no problems with 1Mbps, 2, or even 4. FT2232H, yes.
<ZipCPU>
Digilent board, so Digilent FT2232 implementation
<kc5tja>
Heck, that'd be grand if I can pull that off, but I'm not banking on it.
<ZipCPU>
Go for it.
<ZipCPU>
All my test code is on-line, and even released under LGPL if that interests you.
<ZipCPU>
s/test code/demo code/
<kc5tja>
Wait, is it the case that it's reporting 9600bps because that's what the ioctl settings use, but it's *really* running a 1Mbps?
<ZipCPU>
Depends. What are you setting it to?
<kc5tja>
Again, I don't have anything wired up yet. I'm still planning everything.
<kc5tja>
But, at work, we just stick with 115200.
<kc5tja>
I have no idea what the data rate is behind the FT2232.
<ZipCPU>
115200 is pretty common for a lot of things. It's great when you want a standard serial port speed. It's poor when you want high speed.
<ZipCPU>
The FT2232 declares that it can do 12Mbps. I've never managed to go that high though.
<kc5tja>
On the device side.
<kc5tja>
What does it report to the PC side?
<ZipCPU>
Not sure. Not sure I've ever asked it that question.
<ZipCPU>
minicom will let you go that fast though.
<kc5tja>
So it might be saying, "I support these baud rates," but it just completely ignores that setting then.
<kc5tja>
My minicom preferences only go up to 115200 though.
<ZipCPU>
Couldn't be. I've been successful communicating at 1Mbps and 4Mbps (and I think 2 as well)
<ZipCPU>
I can use AutoFPGA + the board's clock speed to set BAUDRATE. This file then sets the serial port to that speed.
<kc5tja>
To answer your earlier question, though, yes; the peripherals are being designed ahead of any processor logic.
<ZipCPU>
:D
<kc5tja>
But not completely.
<ZipCPU>
:DD
<kc5tja>
That is, the SIA is going to be implemented *just enough* to be able to send data to the host PC, so I can write a small program that prints hello world to the PC, but that's all it can do.
<ZipCPU>
Really? That'd be all? Why only that?
<kc5tja>
Implementing in small steps.
<ZipCPU>
Ok
<ZipCPU>
I need to run, though--it is late here.
<kc5tja>
Minimizing the debugging surface.
<kc5tja>
Good night!
<kc5tja>
Thanks again!
<ZipCPU>
I'm glad I seem to have gotten you moving on your way
<ZipCPU>
I'm still looking forward to hearing you have your 64-bit RISC-V CPU running
<kc5tja>
I've got a Wishbone CPU already.
<ZipCPU>
64-bit RISC-V?
<kc5tja>
Yes.
<ZipCPU>
Ok, I'll need to ask you about that later.
<kc5tja>
KCP53000. It's what powers my Kestrel-2DX. ;)
<kc5tja>
I'd be happy to answer any questions about it.
<ZipCPU>
'nite
kc5tja has quit [Quit: leaving]
lutsabound has quit [Quit: Connection closed for inactivity]