<Sarayan>
whitequark: just tried top-of-tree on m68k.v, it's not entirely working but it's close. I'll try to find out what's going on (looks like it's trying to do a memory read, which is good, but never sets as/uds/lds)
<whitequark>
oh sweet!
<whitequark>
did you ever get it working before? (is this a regression?)
<Sarayan>
No
<Sarayan>
it's a progression :-)
<whitequark>
try using `write_cxxrtl -nohierarchy`
<Sarayan>
there was the issue with the array of clocks, dunno if the PR has been taken into account (not a PR by me)
<whitequark>
it has been
<Sarayan>
cool
<Sarayan>
compiling lalala
<Sarayan>
(it generates a *big* c++ file :-)
<whitequark>
sure does
<Sarayan>
I'm always amused at having to raise the bracket-depth
<Sarayan>
no visible change
<whitequark>
ah, so not that then
<whitequark>
please let me know what the issue is!
<Sarayan>
yeah, when I find it :-)
<Sarayan>
but I shall
mewt has quit [Read error: Connection reset by peer]
<Sarayan>
funnily enough, a lot more stuff happens when you actually raise (disable) the HALTn pin
<Sarayan>
there's a fair chance the 68k actually works
<whitequark>
oooh
<Sarayan>
I wouldn't have guessed that the halt pin halted on the next memory access
<Sarayan>
and not immediately
<Sarayan>
the 68k does 5 micro-ops at reset before starting to read the vectors
<Sarayan>
ok, not only the 68k is working, but it's executing a stream of nops at roughly 200KHz on my laptop
<whitequark>
is that good?
<Sarayan>
well, you tell me, but for that level of emulation I suspect it is
<Sarayan>
1/400th of real time for a typical 8MHz 68k
<Sarayan>
1/40th of real time for a typical 8MHz 68k
<Sarayan>
stop the zero inflation :-)
<whitequark>
seems like there are feedback arcs
<Sarayan>
yeah
<Sarayan>
plan to do a nmigen version at some point. Didn't write that one
<Sarayan>
Just want to be able to bisimulate with a know good low-level core
<Sarayan>
the 68000 has never been designed to be good in a fpga-similar setup :-)
<whitequark>
lemme look at the m68k disassembly
<whitequark>
(yes, i can actually get useful insight from looking at disassembly of C++ templates stacked dozens of levels deep)
<Sarayan>
yeah, but you're special :-P
<Sarayan>
more seriously, I'm not even surprised. The point of the template is to have as little code generated as possible in the first place
<Sarayan>
handholding the compiler in a way
<whitequark>
strangely, no
<Sarayan>
no?
<whitequark>
the way CXXRTL is designed it actually expects the C++ compiler to be very clever
<Sarayan>
It's often to point of my templates, but heh
<whitequark>
like, CXXRTL doesn't really work well without really aggressive loop unrolling and constant propagation
<Sarayan>
ahhh hok I see what you mean
<Sarayan>
I consider that basic, today. It's telling the compiler that "here, that's a constant" that is important
<Sarayan>
we don't have automatic method duplication on various possible values of a variable yet, except for some special cases like memcpy
<whitequark>
yeah, i see what you mean
<whitequark>
that's one way to look at it
<Sarayan>
anyway, *very* *very* happy to have fx68k run under cxxrtl
<whitequark>
the silliest part is that you didn't need to wait since january
<whitequark>
could have just lowered the debug level a bit
<Sarayan>
I wasn't waiting, I was doing a thousand other things :-)
<whitequark>
but no one told you that in the issue, it seems
<whitequark>
ahh okay
<Sarayan>
it's you closing the issue that pushed me into testing
<Sarayan>
in fact you put something back on my todo list, so technically I should hate you ;-)
<Sarayan>
been mapping the m10k tiles on the cyclone v lately, which makes we wonder how one handles specialized blocks like that in nmigen/yosys/nextpnr
<Sarayan>
and in cxxrtl for the matter
<whitequark>
nmigen has Instance, yosys has black boxes, nextpnr knows how to interpret these black boxes
<whitequark>
in cxxrtl you can load the simulation model of the black box
<Sarayan>
nice
<Sarayan>
lots of plumbing on the horizon, but very nice to see all the pieces are there
<tnt>
whitequark: can cxxrtl use the cells_sim.v ?
<tnt>
or do you need to write custom models ?
<lofty>
Sarayan: Yosys handles them as MISTRAL_M10K blocks, which nextpnr would then put in the correct BELs
<whitequark>
you get all the visibility and all the optimization
<Sarayan>
beautiful
<Sarayan>
so I can keep using p_thing for the external interface of the top module, but it's considered a good idea to go through the debug items for what's internal?
<whitequark>
can you keep using p_thing for the ports: yes
<Sarayan>
(I noticed I can get the "uRom microAddr" variable as p_uRom_2e_microAddr)
<whitequark>
you can just use p_uRom_2e_microAddr if you want
<whitequark>
it's purely a matter of your convenience in this case
<Sarayan>
_2e_ is '.' in fact, right?
<whitequark>
other than for ports, CXXRTL does not guarantee that the signals will be exposed as members, and if they do, what name the member will have
<whitequark>
yes
<Sarayan>
microAddr being a port of the uRom submodule that's why it's visible? or it's just pure luck?
<whitequark>
most likely, the net you're looking at has many HDL names
<whitequark>
on many levels of hierarchy, and possibly within a single module, too
<whitequark>
only one of these names ends up as the name of the class member
<whitequark>
and it's kind of arbitrary now
<Sarayan>
cute
<whitequark>
the debug info has all of the names
<Sarayan>
got it grepping the .cc, as one does
<whitequark>
and they alias a single physical wire<> or value<>
<whitequark>
that's what it is: a precise mapping from HDL level names to the physical storage
<Sarayan>
and I get the list through debug_items(items). Surprised you didn't use RVO
<whitequark>
look at the implementation
<whitequark>
consider also that for hierarchical designs (perhaps with blackboxes) you'd have a tree of debug_items functions in the model
<Sarayan>
ok, if you have a tree, ok
<Sarayan>
otherwise it would just have been debug_items items; at the start and return items; at the end
<Sarayan>
I use RVO a lot, it's so natural code-wise
<whitequark>
sure
<Sarayan>
ah, one can't copy debug_item around
<whitequark>
oh, that's unintentional
<Sarayan>
oh cool. it would be nice to make it possible to have global/member ones, which you init at start and use whenever
<whitequark>
it's POD
<Sarayan>
no default constructor though
<Sarayan>
references are POD?
<whitequark>
hm?
<whitequark>
take a look at its definition
<whitequark>
it's a bit weird
<whitequark>
because it inherits all the fields from the struct in the C API, just adds a few methods
<Sarayan>
oh, it's not reference, it's inheritance
<Sarayan>
so the only issue is the lack of default constructor I guess
<whitequark>
well
<whitequark>
it doesn't have a default state
<whitequark>
arguably a design defect, there should've been CXXRTL_INVALID in the type enum or something
<Sarayan>
that means you must have pointers and ensure the lifetime of the items structure you passed debug_items
<Sarayan>
that's unfortunate
<whitequark>
yeah
<whitequark>
you could also cast it to the base class and use that directly