<benny2366[m]>
ok and what do they mean with AttributeError: 'NoneType' object has no attribute 'request'?
<zyp[m]>
there's no platform in simulation, so you can't do platform.request()
<benny2366[m]>
so that means ?
<zyp[m]>
it means that modules that requires a platform can't be simulated
<benny2366[m]>
ok but I mean what are the implications on my programs ?
<benny2366[m]>
so i have to have 3 seperat programs so to speak? 1 that is the design without the board deffinitons ,1 simulation file and 1 file for synthesizing ?
<whitequark[cis]>
yes
<zyp[m]>
typically most of the platform interaction are in the toplevel module in the hierarchy, whereas simulation testbenches typically focus on testing specific submodules
<zyp[m]>
even not considering simulation, a design is typically split into a hierarchy of modules where you have small modules doing specific things, and larger modules building more complex stuff from the smaller modules
<zyp[m]>
and then the toplevel module is mostly just responsible for instancing the major function blocks and hooking it to platform IO
<benny2366[m]>
so like in VHDL/Verilog
<benny2366[m]>
so if i want to do a simple button to led in the left most file i have to do led = button or led <=button?
<zyp[m]>
none of those are correct amaranth
<benny2366[m]>
and what is correct ?
<zyp[m]>
you're looking for something like m.d.comb += led.o.eq(pmod_btn.i)
<benny2366[m]>
ok will do tomorow thanks zyp and catharin !
<benny2366[m]>
also i need to call this ``` m.d.comb``` for combinatorial circuits and ``` m.d.seq``` for sequencial circuits ?
<zyp[m]>
m.d.sync by convention, but comb is the only special domain
<zyp[m]>
you can name clock domains how you like, but for any component that only interacts with a single domain, it's convention to call it sync and if necessary hook it to a more specific name higher up in the hierarchy
<jorolf[m]>
How can I avoid signal merging? I need to have to signals with different attribute values (but the same key) and because they are driven by the same signal (in this case a const) the attributes get merged in the resulting verilog file
<jorolf[m]>
s/to/two/
<jorolf[m]>
As in, I still have 2 signals but the attributes of both are the same when they should be different
<jorolf[m]>
Hmm, I'll try to get a test working in the playground
<jorolf[m]>
However if you change line 31 to first.eq(1) then suddenly it works
<benny2366[m]>
looking at that example it now makes sense , actualy feel stupide right about now XP
<benny2366[m]>
ok so coppied the example (the main part in my main code and the testbench part in my testbench script) but now I get the error File ```"c:\Users\bende\Documents\GitHub\amaranth_playground\program1\buttontoled_TB.py", line 4, in <module>
<benny2366[m]>
dut = buttontoled()
<benny2366[m]>
TypeError: 'module' object is not callable```
<threeflour[m]>
In python when you write import foo, foo will be a module object which represents the namespace of the module foo. You need either to write from buttontoled import ButtonToLed or dut = buttontoled.ButtonToLed()
<jorolf[m]>
It says that it had to route it using a "non-dedicated" path (probably a direct path from the IO to the BUFG). It might still work by using an indirection which is why you can demote it to a warning. However, if you include the & operation then it already has that indirection because of the needed lookup table
<jorolf[m]>
(Atleast that's what I think)
<jorolf[m]>
Although generally you shouldn't cross the data<->clock boundary
<lightleopard[m]>
That makes sense
<lightleopard[m]>
Related question: what's the preferred way for checking for edges in signals?
<lightleopard[m]>
I guess just copying the signal into a sync flip-flop with `m.d.sync += last_signal.eq(signal)` and then checking `signal & ~last_signal`? Or is there a better way?
<jorolf[m]>
Afaik there is no better way
<lightleopard[m]>
Great, thanks a lot
<lightleopard[m]>
* a lot!
<jorolf[m]>
lightleopard[m]: Altough in your case you should make sure that the button is debounced
<lightleopard[m]>
Yeah you're right, I've been going crazy trying to press them gently during testing
<lightleopard[m]>
Is there a method you'd suggest? Or just a counter to add a delay?
<jorolf[m]>
A counter is what I would've used. Altough tbf I've never really looked into that
<whitequark[cis]>
<jorolf[m]> How can I avoid signal merging? I need to have to signals with different attribute values (but the same key) and because they are driven by the same signal (in this case a const) the attributes get merged in the resulting verilog file
<whitequark[cis]>
I think this is basically a bug; I recommend reporting it and working around it for now by instantiating a primitive like LUT1
<whitequark[cis]>
in between the two signals
<jorolf[m]>
Yeah I've worked around it by inverting the signal twice
<zyp[m]>
maybe also reset the count every time you see bounce
<lightleopard[m]>
It looks great
<lightleopard[m]>
Will try it, thanks!
V has joined #amaranth-lang
<whitequark[cis]>
there's an interesting quirk of debounce circuits
<whitequark[cis]>
if you're working on something that involves a fast reaction time (e.g. a fast paced shooter game), it's actually better to assert the output the moment the input gets asserted, then ignore deassertions until it stops bouncing
<whitequark[cis]>
in lightleopard's application it likely won't matter, but i think zyp might find this a fun quirk
V has quit [Quit: We're here. We're queer. Connection reset by peer]