<modwizcode>
hmm I didn't realize that about the clocking, something about that feels problematic to me. I think I don't like the idea that I can't actually divide a clock which I didn't actually realize.
<modwizcode>
that clock balancing, would that be happening manually then?
<whitequark>
which part feels problematic to you?
<modwizcode>
not problematic as in wrong, problematic in the sense I don't like the truth.
<whitequark>
oh. um.
<whitequark>
that's an interesting way to feel about it :D
<whitequark>
but yeah it's been bothering me too
<modwizcode>
So there's no deterministic way in the HDL to divide down the clock? (This is the truth I don't like)
<modwizcode>
Other than enables
<whitequark>
it... depends
<whitequark>
if you're using a strict Verilog simulator, you can use = in the divider
<whitequark>
if you're using a strict VHDL simulator, you can balance clock trees
<whitequark>
(you might ask: what about mixed VHDL/Verilog code? to which I will not provide an answer)
<whitequark>
if you're using Verilator, I think that has some custom attributes
<whitequark>
if you're using CXXRTL, you kinda just can't at the moment at all.
<modwizcode>
I think all of my work projects are mixed... for reasons. But I don't trust my simulators down to the delta cycle either anyway.
<modwizcode>
Fixing CXXRTL to have a deterministic solution seems important. But attributes feel like a bad route.
<whitequark>
CXXRTL explicitly implements synthesis semantics, which in case of a clock divider are "like, whatever"
<modwizcode>
Anyway in VHDL that's me doing the balancing, not the simulator right?
<whitequark>
yes, in VHDL you do it manually
<modwizcode>
When I read it originally I was assuming that balancing happens under the hood but then I realized that's like impossible and makes no sense.
<whitequark>
yes. you have to think about it. it is not a happy set of thoughts, usually.
<whitequark>
I don't know how would one debug this beyond "staring intensely" and that's even worse
<modwizcode>
For it to be automatic it would have to understand what you want out of the logic in a way that I doubt is possible. Maybe attributes could coax it into doing it for you, but again yikes.
<whitequark>
no no, it can be automatic.
<whitequark>
consider this: the PNR tool must know which clocks are related, and PLLs can divide clocks
<modwizcode>
Right but you have to tell it that you're using a PLL somehow or that something is a clock.
<whitequark>
in order to correctly route a design that has a CDC between two related clocks without additional synchronization (ie no 2FFs everywhere) you need to be able to tell the PNR tool the relationships between clocks
<whitequark>
yes. you can use a similar method to tell CXXRTL about this relationship/
<whitequark>
*.
<whitequark>
it could be attributes, or it could be a .sdc file, or it could be honestly whatever, the important part is actually scheduling according to that
<modwizcode>
Yeah this is the part that my knowledge is pretty weak on.
<modwizcode>
Oh wait.
<modwizcode>
Okay I think what you said clicked a bit better there.
<whitequark>
remember those edge detectors?
<modwizcode>
unfortunately yes
<whitequark>
you have to arrange the scheduling so that edge detectors for in_clk and out_clk trigger in the same delta cycle
<modwizcode>
oh
<whitequark>
(or so that the design behaves as-if they do)
<whitequark>
that's it
<whitequark>
very simple
<whitequark>
"simple".
<modwizcode>
there's a way to do this already then? (You'd think with me poking through the scheduling code properly I would know)
<modwizcode>
but what I saw suggests not
<whitequark>
no, I was saying "simple" sarcastically
<whitequark>
it's one of the hardest problems I've encountered in EDA so far
<modwizcode>
ohhh
<modwizcode>
Yeah okay that's what I thought you were saying
<whitequark>
I don't think it requires anything fundamentally new, it's a small open research problem
<modwizcode>
the computed clock's edge detectors have to have a scheduling dependency on the statements that compute the divide clock right?
<modwizcode>
And then anything that depends on that clock has to have a scheduling dependency placing it after that clock itself. Or something...
<modwizcode>
*the edge detector itself
<whitequark>
sssomething like that
<whitequark>
but
<whitequark>
note that when you have feedback arcs in a single clock designs, the scheduling dependencies being violated aren't a big deal. you just want as few of them violated because it improves performance.
<whitequark>
however if you have feedback arcs with edge detector dependencies, you can't just do that
<whitequark>
also, we can't just reject them either
<modwizcode>
right that's basically what I was thinking about
<whitequark>
because our approach to the feedback arc set problem is inexact
<modwizcode>
If it were exact would it be solved?
<whitequark>
if there was a way to say "never break these edges unless absolutely necessary" then yes
<modwizcode>
okay I was only asking to validate that I was thinking about things the right way
slan has quit [Remote host closed the connection]
<modwizcode>
but wait. if the edges ever break aren't you screwed? Because now that's not the same delta cycle?
<whitequark>
yes, so you need to display a diagnostic
<whitequark>
however, it might be possible to break a lot of *other* edges instead
<whitequark>
since a FAS solution is not necessarily unique
<whitequark>
the current algorithm heuristically computes an approximation to MFAS but with the edge detector dependencies you can no longer just use MFAS
<modwizcode>
At some point I should read that paper I put it off bc it was fairly math syntaxy which I find difficult to parse.
<whitequark>
it's kind of not all that readable yeah
<whitequark>
like even if you're fine with mathy syntax
<modwizcode>
I skimmed it and concluded that on it's own I had no idea how I would know it's relevant at all to what CXXRTL does (i.e. that the FAS stuff is connected to anything meaningful)
<whitequark>
well, a netlist is a graph that describes parallel computation, and a C++ function is serial, so you want to compute a sequence of nodes such that by the time you compute the outputs of a cell, all of the inputs have already been computed
<whitequark>
a feedback arc is an input that is not computed by the time you are computing the outputs.
<whitequark>
zero feedback arcs? one delta cycle. fewer feedback arcs? fewer delta cycles
<whitequark>
note that FAS can only be used to reliably schedule netlists that have no logic loops
<whitequark>
in other words, you can only use FAS to schedule a netlist if the consequence of computing the outputs when the inputs haven't been computed is benign, i.e. an extra delta cycle
slan has joined #nmigen
<modwizcode>
yeah that's basically my understanding of things so far.
<whitequark>
netlists with logic loops (we are mostly interested in stable logic loops, i.e. latches) can behave unreliably, since we disregard the side effects of computing the outputs of them.
<whitequark>
yeah
<modwizcode>
this implies now that I realize it that there might be use for a false path type of indication in cxxrtl, since certain inputs connected to outputs might not care about the intrinsic race conditions. Although given the way cxxrtl works I'm not sure if that might horribly break things.
<whitequark>
this already exists
<whitequark>
check out the help text for black boxes
<modwizcode>
I am not surprised to hear it
<modwizcode>
I have ignored most of the black box stuff as I have not needed it yet
<whitequark>
what it calls "sync outputs" is essentially equivalent to what you call "false path" here
<modwizcode>
right
<whitequark>
CXXRTL black boxes are kinda neat because you can have combinatorial feedback and still fit into one delta cycle
<modwizcode>
Hmm
<whitequark>
I'm not aware of any other simulator that can do it
<modwizcode>
So you're saying if I put all the messy stuff into that it will work
<whitequark>
I believe verilator would need at least two
<whitequark>
well... not necessarily
<modwizcode>
Uh correction then. it *might* work
<whitequark>
black boxes are scheduled at the granularity of, well, black box
<whitequark>
if you have some signal zipping back and forth between black box inputs and outputs, no dice
<whitequark>
but having a single combinatorial "ack" is generally fine
<modwizcode>
I know there's a comment in the code describing this (because I've read it) but the fact that "sync output" is combinational is definitely confusing.
<modwizcode>
I understand *why* it's called that, but it doesn't making it not still initially confusing
<whitequark>
er
<whitequark>
it's not combinatorial
<whitequark>
you mark the ack as a comb output. you mark (usually) all others as sync
<modwizcode>
oh than I misunderstood
<whitequark>
I mean it depends on the black box in question but if you need Wishbone with combinatorial ack, this is what you'd do
levi has joined #nmigen
<_whitenotifier>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JtsTm
<_whitenotifier>
[nmigen/nmigen] whitequark a2da34a - README: add ChipEleven as a sponsor.
<_whitenotifier>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JtsTO
<_whitenotifier>
[nmigen/nmigen] whitequark 10ca62b - Deploying to gh-pages from @ a2da34a5bc5b5e1be8d0a94e579ab4ea5a876868 🚀
<cr1901_modern>
>ChipEleven
<cr1901_modern>
Huh, that's cool... we get a free tiny POWER CPU and free big POWER CPU
<modwizcode>
neat
<cr1901_modern>
(the tiny one being microwatt)
<tpw_rules>
is that lkcl's work?
<modwizcode>
I've never heard of them until now interesting
<sorear>
no
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter_ is now known as PyroPeter
emeb has quit [Quit: Leaving.]
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined #nmigen
Bertl_oO is now known as Bertl_zZ
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
pftbest has quit [Remote host closed the connection]
JJJollyjim has quit [*.net *.split]
JJJollyjim has joined #nmigen
whitequark[m] has quit [Ping timeout: 244 seconds]
emily has quit [Ping timeout: 243 seconds]
blazra has quit [Ping timeout: 260 seconds]
JJJollyjim has quit [Ping timeout: 258 seconds]
vmedea[m] has quit [Ping timeout: 265 seconds]
jfng has quit [Ping timeout: 260 seconds]
cesar[m] has quit [Ping timeout: 268 seconds]
jjeanthom has joined #nmigen
pftbest has joined #nmigen
whitequark[m] has joined #nmigen
emily has joined #nmigen
cesar[m] has joined #nmigen
emily has quit [Ping timeout: 240 seconds]
cesar[m] has quit [Ping timeout: 240 seconds]
whitequark[m] has quit [Ping timeout: 260 seconds]
cesar[m] has joined #nmigen
vmedea[m] has joined #nmigen
emily has joined #nmigen
whitequark[m] has joined #nmigen
JJJollyjim has joined #nmigen
blazra has joined #nmigen
jfng has joined #nmigen
futarisIRCcloud has joined #nmigen
bvernoux has quit [Read error: Connection reset by peer]
jjeanthom has quit [Ping timeout: 244 seconds]
jjeanthom has joined #nmigen
jjeanthom has quit [Ping timeout: 258 seconds]
pftbest has quit [Ping timeout: 244 seconds]
jjeanthom has joined #nmigen
pftbest has joined #nmigen
<lkcl>
tpw_rules: no, they're... a team that betrayed our trust by screwing us over when speaking to investors
<lkcl>
they've caused an awful lot of damage by not pathologically not listening to feedback, yet truly and firmly believe that they are "good".
<lkcl>
it's a dangerous combination.
<lkcl>
one that, sadly, is quite common
<d1b2>
<dub_dub_11> :( what was the feedback concerning
<lkcl>
5 people advised them how to speak to investors, regarding the software license, to keep it libre rather than non-free (non-commercial)
<lkcl>
it's a long list and much of it is confidential, i apologise.
<lkcl>
bottom line they've pissed off a *lot* of very powerful people
<d1b2>
<dub_dub_11> Ah right
<d1b2>
<dub_dub_11> I think I vaguely remember this topic
<d1b2>
<dub_dub_11> What is the difference between libre and non-free (non-commercial)
<lkcl>
essentially, "we develop everything publicly and transparently, all code and all technical discussions are available in real-time"
<lkcl>
vs
<lkcl>
"we keep everything closed, but promise *eventually* to release source code, but when we do you can't use it for commercial purposes"
<d1b2>
<dub_dub_11> Ah
<d1b2>
<dub_dub_11> So libre is actually open source Vs ... Not
<lkcl>
for a while they tried to take libre-soc LGPLv3-licensed source code and slap a non-commercial license on it without permission
<lkcl>
aka "Fake Open Source", yes.
<lkcl>
anyway - that's enough of tha, if that's ok dub. this is nmigen.
<d1b2>
<dub_dub_11> I'm not an expert on licensing but I remember enough to know that GPL states you can't change the licence terms
<d1b2>
<dub_dub_11> Yeah you're right
Bertl_zZ is now known as Bertl
jjeanthom has quit [Ping timeout: 264 seconds]
<lkcl>
correct: and, also, you cannot take someone else's copyrighted material (jointly or otherwise, majority or otherwise) and slap a different license on it.
chipmuenk has joined #nmigen
nfbraun has joined #nmigen
<nfbraun>
Is there a way to use input delay elements (e.g. IDELAY on Xilinx 7series) from nMigen proper (without instantiating vendor-specific primitives)?
<nfbraun>
Seems more or less required for DDR input...
<mwk>
not at the moment
<mwk>
they're in general too hardware-specific to be usefully specifiable in generic code
<nfbraun>
For the runtime-configurable variant I'd agree, but the fixed variant (a fixed delay specified at bitstream generation time) should be doable?
<nfbraun>
Then again, I never really used other FPGA families...
<mwk>
like, just specify the delay in ns? I suppose that would be doable, except not all FPGAs can actually do that
<mwk>
since it requires some calibration scheme in hw
<mwk>
and even on 7series, getting it working is nontrivial
<mwk>
since you have to set up IDELAYCTRL and need a 200MHz reference clock for that
<mwk>
doing that automatically inside a synthesis tool? not going to happen
<nfbraun>
I guess that is true, the user would probably need to take care of the reference clock manually. Which kind of negates the whole point of having this integrated.
<mwk>
I'm thinking it could be integrated, just not in a generic way
<mwk>
like, the platform code already instantiates vendor primitives for IOs, you could make it do more with vendor-specific parameters
<mwk>
not sure if it's a good idea thoug
<d1b2>
<dub_dub_11> the Libraries Guide says the primitives need to be instantiated manually, and can't be inferred so basically yeah it would have to be manually coded in specific to the platform
<d1b2>
<dub_dub_11> and there's quite a long list of primitives that can only be instantiated 😅
<mwk>
what xilinx tools can infer or not is besides the point here
<mwk>
nmigen already has generic support for DDR, which likewise has to be manually instantiated in verilog
<mwk>
the question is whether the relevant primitives are consistent enough between various FPGA types that you can actually feasibly write platform-independent code
<nfbraun>
Yes. I was thinking something along the lines of platfrom.request("foo", xdr=2, delay=1200).
<mwk>
eg. IMO it'd be nice if stuff like xilinx BUFGCE was instantiable by an nmigen primitive
<d1b2>
<dub_dub_11> yes, but the generic support is implemented by manually inferring a primitive (just in the platform script not the user)
<d1b2>
<dub_dub_11> yeah that's what I mean, there are other things and it's hard to decide what should be left to user instantiation and what nmigen could support
<d1b2>
<dub_dub_11> like a BUFGCE, or DSP, or BRAM
<d1b2>
<dub_dub_11> or PLLs which is sort of being worked on now I think
<nfbraun>
Thanks for the answer. I have it running with Instance()s and will stick to that for the time being.
<d1b2>
<dub_dub_11> (which btw mwk if there are extra primitives for the Xilinx platform I could help with adding support for I'd be happy to)
<mwk>
not that I know of
<mwk>
it'd be nice to have a set of nice nmigen wrappers for various platforms, and for I/O stuff perhaps even integrate it with usual I/O instantiation, but we don't have anything like that yet
<d1b2>
<dub_dub_11> that's kinda what I meant yeah
<nfbraun>
mwk: FWIW, I tested your "unify Xilinx platforms" PR (#563) on Zynq and I seemed to work, at least until I ran into the issue that I needed delays.
<mwk>
well it doesn't really change anything for Zynq
<mwk>
... I mean unless you want to synth with ISE for some strange reason
<nfbraun>
No :)
<d1b2>
<dub_dub_11> the two I've been playing around with recently are BRAM and DSP. You can get BRAM usage easily enough with generated code but when I tried to use the pipeline registers (which requires instantiation) and initialise the contents it was a real headache so I have a wrapper that might help with that usecase (maybe with some cleaning up).
<mwk>
huh, pipeline registers require instantiation? that's news to me
<d1b2>
<dub_dub_11> similar issues with DSP blocks you might remember me asking about, where I wanted a multiply-accumulate but the generated code meant I was getting the accumulator in fabric. So likewise I'd be happy to make a wrapper for instantiating DSP (which seems like a much bigger task than BRAM)
<mwk>
mhm
<mwk>
... of course the interesting part with both of those two is not actually emitting the instance
<mwk>
but also getting the damn thing simulatable
<nfbraun>
BTW: how usable is the Symbiflow toolchain on Zynq? Is this worth trying out already?
<d1b2>
<dub_dub_11> maybe the pipeline registers can be inferred in Vivado? I'm working with V5 and ISE, and I definitely remember somewhere saying you needed instantiation
emeb_mac has joined #nmigen
<d1b2>
<dub_dub_11> ah here we go: UG190, BRAM Library Primitives: "Some block RAM attributes can only be configured using one of these primitives (e.g., pipeline register, cascade, etc.)"
<d1b2>
<dub_dub_11> I see what you mean wrt simulation though, as I don't know to what extent if at all you can use the vendor sim model
zignig has quit [Quit: Lost terminal]
_whitelogger has joined #nmigen
<d1b2>
<dub_dub_11> that doesn't necessarily mean it is accurate tbf
<modwizcode>
I'm fairly certain you have to manually specify those
<modwizcode>
All the code I've seen goes through that process.
<mwk>
that's... interesting
<modwizcode>
Is it?
<modwizcode>
I'
<modwizcode>
oops
<mwk>
sounds like kind of an easy thing to implement and I'm surprised they didn't do that
<mwk>
well, relatively easy
<d1b2>
<dub_dub_11> yeah it doesn't seem hard to think of an inference template
<modwizcode>
I think their reasoning was probably that other parameters are not so easy to infer, so rather lets not infer only some of them
<d1b2>
<dub_dub_11> basically just any synchronous read lol
<modwizcode>
It's definitely possible the docs are wrong though, maybe I should test it. Although I'm not 100% sure how I'd verify :p
<d1b2>
<dub_dub_11> I have tried on ISE at least, when doing it by inference and using PlanAhead to look at the layout it put the output registers in fabric and the highest frequency I could hit was like 330MHz
<d1b2>
<dub_dub_11> same design but instantiated BRAM with the pipeline register option, easily met timing at 450MHz which is the BRAM switching limit
<modwizcode>
I can check in vivado
<modwizcode>
where is the spec for the limit defined btw?
<d1b2>
<dub_dub_11> uh probably ug473
<d1b2>
<dub_dub_11> wait no
<d1b2>
<dub_dub_11> it will be the dc and switching datasheet
<modwizcode>
I don't remember how xylinx license work. I wonder if i can make a zynq-7000 design
<d1b2>
<dub_dub_11> well what part/board do you have
<modwizcode>
I don't remember lol
<modwizcode>
I'll have to check
<d1b2>
<dub_dub_11> 😄
<d1b2>
<dub_dub_11> https://github.com/H-S-S-11/numerically-controlled-oscillator you might be able to adapt nco_lut, nco_lut_pipelined, tone_synth to something you can use to compare the inferred vs pipelined lut. Sorry for the mess... I've promised myself I will organise it at some point
GenTooMan has quit [Quit: Leaving]
<modwizcode>
Hmm
<d1b2>
<dub_dub_11> (ofc if it doesn't make any sense which is highly possible then just ignore it 😅
<modwizcode>
I'm just trying to understand what's going on in this code XD
<d1b2>
<dub_dub_11> yeah I should really comment everything 😐
<modwizcode>
I mean it's not awful it's just a new codebase to me
<d1b2>
<dub_dub_11> nco_lut is a sine wave generator so it uses a large BROM
<modwizcode>
nco_lut doesn't instantiate the BROM? it relies on inference from the switch statement?
<d1b2>
<dub_dub_11> correct
<modwizcode>
we know it infers correctly as is?
<d1b2>
<dub_dub_11> it infers BRAM, initialises it, all great... except, even though the output is assigned in the sync domain, it won't use the output registers
pftbest has quit [Remote host closed the connection]
<d1b2>
<dub_dub_11> so when you look at the resource usage/layout viewer you will see that sin_o is in FFs in fabric
pftbest has joined #nmigen
<modwizcode>
Okay
<d1b2>
<dub_dub_11> and if you try stretch the timing constraints, I would expect you to see the path from BRAM inputs to the sin_o FFs become the critical path
<modwizcode>
I will try to instantiate this in a design. I'm probably going to convert it to verilog and paste it into the IDE :p
<modwizcode>
but I will do that in a few hours because I have other things to do at the present moment
<d1b2>
<dub_dub_11> fair enough
<d1b2>
<dub_dub_11> tone_synth feeds the output into a pwm module but it's not really important where it goes
<d1b2>
<dub_dub_11> it's probably a better test without the pwm tbh
<modwizcode>
Yeah I think I'll bypass that and just focus on nco_lut and nco_lut_pipelined directly
<modwizcode>
why does one of them instantiate a PLL and the rest don't out of curiousity
<d1b2>
<dub_dub_11> uhh I was playing around 😛
<d1b2>
<dub_dub_11> I've not actually run any of them at 450MHz, only put that as the timing constraint and done STA
pftbest has quit [Ping timeout: 246 seconds]
<d1b2>
<dub_dub_11> the bram wrappers are in bram_instantiation
<d1b2>
<dub_dub_11> they're very much a "hacked together to do what I needed at the time" version though, and would benefit from me spending more time to flesh out things like the initialisation data generator
<agg>
whitequark: if you get a few minutes, could i ask for a quick look at https://github.com/nmigen/nmigen/pull/578 please? I hope it should be pretty straightforward
jjeanthom has joined #nmigen
jjeanthom has quit [Ping timeout: 246 seconds]
jjeanthom has joined #nmigen
jjeanthom has quit [Ping timeout: 260 seconds]
<whitequark>
agg: looking now
<_whitenotifier>
[nmigen] whitequark closed pull request #578: ECP5: Replicate OE FF for each output bit - https://git.io/JtJci
<_whitenotifier>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JtsKY
<whitequark>
agg: thank you!
<_whitenotifier>
[nmigen/nmigen] adamgreig 6ce2b21 - vendor.lattice_ecp5: replicate OE signal for each output bit.
<agg>
thanks :)
<agg>
i am slowly fuzzing out more ECP5 DSP bits, hopefully have nextpnr doing a working MAC sometime soon
* agg
swaps nmigen back to master branch
<_whitenotifier>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JtsKZ
<_whitenotifier>
[nmigen/nmigen] whitequark 403c433 - Deploying to gh-pages from @ 6ce2b21e196a0f93b82748ed046098331d20b3bf 🚀
<whitequark>
wonderful
<miek>
agg: ooh, nice!
<awygle>
whitequark: re: that PR - the only way to do xdr=4 with dir=io on the ECP5 is using the DQS modules for memory, according to daveshah. is that something nmigen should deal with, either by throwing some specific error or by trying to autogen the memory stuff?
<modwizcode>
agg: what's the workflow you're using to figure out the bits?
<awygle>
Probably not the latter one, that seems Difficult
<daveshah>
You can't really autogen the memory stuff as you need to have a DQS
<agg>
(d1b2 is a Discord bridge, so the specific user is the name in <> at the start of the message)
<modwizcode>
@dub_dub_11 uhh so weirdly running the generated verilog in the simulator seems to simulate very differently. Which doesn't make sense to me at all...
<d1b2>
<dub_dub_11> oh are you using the vendor primitives to simulate
<ChipEleven>
agg, thanks. Noted.
<modwizcode>
no
ChipEleven has quit [Quit: Connection closed]
<modwizcode>
I'm just testing the one that does inference
<d1b2>
<dub_dub_11> ah
<d1b2>
<dub_dub_11> wdym by differntly?
<modwizcode>
I was checking sim before I synthized and such to make sure it's the same
<modwizcode>
uh by differently I mean clearly wrongly hmm ss might help
<d1b2>
<dub_dub_11> ah, have you got the right radix
<modwizcode>
Actually yeah
<modwizcode>
I was going to uh check that
<d1b2>
<dub_dub_11> think it defaults to signed
<d1b2>
<dub_dub_11> but gtkwave or we will do unsigned
<d1b2>
<dub_dub_11> sooo it will look kinda weird
<modwizcode>
Yeah you're right I'm just being dumb
<modwizcode>
actually it looks like signed is the one that looks right in vivado
<d1b2>
<dub_dub_11> yeah that should be the case
<modwizcode>
Weirdly now GTK wave's looks wrong
<modwizcode>
OH
<d1b2>
<dub_dub_11> oh it's a pain on gtkwave
<modwizcode>
I know why. god I'm stupid. I was originally looking at the phi signal by mistake. Which is why I saw a different, but I was looking at the right signal in vivado
<d1b2>
<dub_dub_11> if you want to do an analog wave you have to click signed decimal, then go back and click analogue
<d1b2>
<dub_dub_11> ah
<modwizcode>
that is
<modwizcode>
very dumb
richbridger has joined #nmigen
<modwizcode>
@dub_dub_11 how do I know if it's a pipeliend blockram in the viewer? I can't make heads or tails of it
<d1b2>
<dub_dub_11> if you click on it you should see the attributes of the primitive, including the DO_reg or whatever it is called
<modwizcode>
ok I tried to do that but I didn't see any related properties hmm
<modwizcode>
I see DOA_REG=1, DOB_REG=0
<d1b2>
<dub_dub_11> DOA_REG
<d1b2>
<dub_dub_11> that's the one
<d1b2>
<dub_dub_11> yeah so that's a pipelined bram
<modwizcode>
Yeah so vivado inferred a pipelined bram
<d1b2>
<dub_dub_11> oh interesting
<d1b2>
<dub_dub_11> this was with nco_lut.py?
<modwizcode>
yes
<d1b2>
<dub_dub_11> neat
<modwizcode>
I'm trying to see what it decided as fmax
<d1b2>
<dub_dub_11> yeah that's the other thing is to push that, in theory if it's pipelined and there's nothing else in the design you should be able to hit the switching limit of the bram
<modwizcode>
do I just have to calculate this from the slack? It seems vivado doesn't dump out an estimated fmax
<d1b2>
<dub_dub_11> well you can get an idea of the delay paths looking through the timing report
<d1b2>
<dub_dub_11> but you won't know the "true" fmax unless you keep decreasing the period constraint until it fails
<modwizcode>
And then there's the effort setting for the place and route (Implementation as vivado calls it
<modwizcode>
Well I couldn't do 450MHz at least on the default effort settings
<d1b2>
<dub_dub_11> what's your part
<modwizcode>
I just kinda picked one at random maybe I should have asked what you were using
<modwizcode>
I went with a xc7z010clg400 speed grade -1
<d1b2>
<dub_dub_11> the limit will be the switching limit for your part and speed gradfe
<modwizcode>
I assume I probably need a better part or speedgrade but I was hoping it'd be achievable without actually picking one