05:56 <qwebirc3348> I need to write a test bench for my D flip-flop http://pastebin.com/w4jazbqb

05:57 <qwebirc3348> I would like to control the clock and also feed a random data as shown here http://www.myhdl.org/doku.php/cookbook:ff

05:58 <qwebirc3348> Could anyone help me in writing one ?

05:58 <qwebirc3348> I need to know how to control the clock signal - In migen for synchronous circuits, automatically the reset and clock signals come

05:58 <qwebirc3348> how to access these ?

08:35 <qwebirc3348> Hi, I found the solution http://pastebin.com/BcJ8BaRf

13:03 <qwebirc44805> I have finished my D flip flop http://pastebin.com/BcJ8BaRf

13:03 <qwebirc44805> In my simulation part

13:03 <qwebirc44805> def do_simulation(self,s): s.wr(D,randrange(2))

13:03 <qwebirc44805> s.wr copies the data only after the positive edge of the clock

13:03 <qwebirc44805> is there any ways to move it to the negative clock ?

13:04 <qwebirc44805> i.e copy in the negative clock ?

13:41 <lekernel> qwebirc44805, no, why would you need that?

13:42 <lekernel> do it in the previous cycle

13:47 <ysionneau> lekernel: compiling gcc 4.8.2 for target lm32-elf takes almost all my RAM (on 4 GB machine) to compile gcc-4.8.2/newlib/libc/argz/'`argz_create.c and then it does an ICE

13:48 <ysionneau> I cannot even compile it

13:48 <ysionneau> it says to submit a bug report :)

13:48 <ysionneau> does it mean they will care about it ? =)

13:52 <lekernel> I don't think so

13:52 <lekernel> have you done a stack trace? perhaps that's the infinite recursion bug I mentioned

13:54 <lekernel> but then someone has to dig deep into the gcc code to fix it

13:54 <lekernel> maybe ask your contact at embecosm

13:55 <ysionneau> http://pastebin.com/R6ijccLX < I've got this kind of error

13:55 <ysionneau> yes I think I will end up asking him ^^

13:57 <ysionneau> is this the stack trace you are talking about?

13:59 <lekernel> hmm, that looks like a new bug

14:03 <ysionneau> I'm using latest version of each component : binutils mpc mpfr gmp gcc newlib

14:03 <ysionneau> latest release of each*

14:04 <ysionneau> maybe it's not the wiser move :p

14:04 <ysionneau> let's try to see if Jörn has any idea about that

14:38 <qwebirc3869> while writing test bench, how can I access the reset and clock ? can I access it using s.we ?

14:39 <ysionneau> I think it's something like s.rd(your_signal)

14:39 <ysionneau> like s.rd(self.your_signal_nameà

14:39 <ysionneau> )

14:40 <ysionneau> have a look at https://github.com/m-labs/migen/blob/master/examples/sim/basic1.py

14:41 <qwebirc13993> what about reset ?

14:42 <ysionneau> what do you mean ?

14:43 <ysionneau> if you want to write the reset signal during your simulation you can do something like : s.wr(self.rstsignal_name)

14:43 <qwebirc13993> what should I do if I want to set the reset on a synchronous circuit

14:45 <qwebirc13993> OK thanks

14:49 <lekernel> qwebirc13993, why do you want to access the reset and clock?

14:50 <qwebirc13993> to control from the test bench

14:51 <lekernel> sure, but why?

14:51 <lekernel> don't the autogenerated signals suit you?

14:52 <qwebirc13993> I don't know how to use them.

14:53 <lekernel> you have a perpetually toggling clock, and a reset signal active at the beginning

14:53 <qwebirc13993> I.e access them

14:53 <lekernel> it's automatically connected to "sync" statements

14:53 <lekernel> why do you want to access them? they are already driven by default, with a pattern that suits most uses imo

14:53 <lekernel> especially as it seems your code is just a DFF - you don't need anything complicated

14:53 <qwebirc13993> I.e self.sync.rst ?

14:54 <lekernel> self.sync.rst accesses sync statements in a clock domain named "rst", which is probably not what you want

14:55 <lekernel> "self.sync += <statement>" adds a statement that is executed at each cycle of the autogenerated simulation clock

14:55 <lekernel> it's simple as that

14:56 <lekernel> you can look at the VCD file if you don't believe me about the autogenerated clock/reset

14:57 <lekernel> if you really need to access the reset signal, you have to define a clock domain yourself

15:00 <qwebirc20659> sorry. I am the d flip flop guy

15:02 <qwebirc20659> currently I am traveling in train . my connection is getting reset and so I might show in a new name

15:05 <lekernel> <lekernel> self.sync.rst accesses sync statements in a clock domain named "rst", which is probably not what you want

15:05 <lekernel> <lekernel> "self.sync += <statement>" adds a statement that is executed at each cycle of the autogenerated simulation clock

15:05 <lekernel> <lekernel> it's simple as that

15:05 <lekernel> <lekernel> you can look at the VCD file if you don't believe me about the autogenerated clock/reset

15:05 <lekernel> <lekernel> if you really need to access the reset signal, you have to define a clock domain yourself

15:05 <qwebirc20659> while testing my d flip flop i wasn't too test it by controlling the reset myself

15:05 <lekernel> that will work. you don't need to test it.

15:06 <qwebirc20659> thanks. I will contact later. thanks for clarifying my doubts

15:06 <lekernel> resets are one thing Migen handles automatically for you, and it's bug-free in much more complex cases than a DFF

17:34 <davidc__> yeah; resets generally 'just work', well, for a single synchronous clock domain :)

17:36 <lekernel> simulation only supports one clock domain atm

17:37 <larsc> does migen insert a async FF for cross clock dmain resets?

17:37 <lekernel> you have to connect reset signals manually, and insert the appropriate synchronizers

17:39 <davidc__> lekernel: yeah.. I have some horrific code for multidomain

18:24 <qwebirc18366> does anyone know why s.wr copies the data only after the positive edge of the clock

18:24 <qwebirc18366> ?

18:25 <qwebirc18366> just for reference - my flipflop s.wr copies the data only after the positive edge of the clock

18:25 <qwebirc18366> sorry

18:25 <qwebirc18366> just for reference - my flipflop http://pastebin.com/BcJ8BaRf

18:26 <qwebirc18366> are there any reasons for having such a design ?

18:27 <davidc__> qwebirc18366: for synchronous designs; this is typically the model you want

18:27 <qwebirc18366> it really confused me for some time when i simulated my flip flop

18:27 <davidc__> qwebirc18366: IE, the s.wr is for providing stimulation for the next cycle

18:28 <qwebirc18366> oh!

18:28 <davidc__> (well, in do_simulation)

18:48 <qwebirc18366> when i simulated the d flip flop, in gtkwave I was expecting this http://macao.communications.museum/images/exhibits/2_19_0_1.png

18:48 <qwebirc18366> but since s.wr copies the data only after the positive edge of the clock there was a big confusion

18:50 <qwebirc18366> I thought migen had options like delaying the clock and also updating data in the negative clock cycle http://www.myhdl.org/doku.php/cookbook:ff

19:29 <lekernel> qwebirc18366, migen != myhdl

19:30 <lekernel> migen has the synchronous concepts built-in

19:30 <lekernel> myhdl is like verilog/vhdl

19:32 <lekernel> if you want to delay clocks or do stuff on negative edges with migen, you have to define new (synchronous) clock domains. which matches the way the virtually all designs are done... not the lower-level one-delay-per-signal that verilog/vhdl has, and which wastes a lot of engineer time