http://www.softwaretools.in Mon, 14 May 2012 06:20:01 +0000 en hourly 1 http://wordpress.org/?v=3.3.2 http://www.softwaretools.in/digital-logic-simulation-with-the-intel-tbb-flow-graph-part-2-building-bigger-components http://www.softwaretools.in/digital-logic-simulation-with-the-intel-tbb-flow-graph-part-2-building-bigger-components#comments Mon, 14 May 2012 06:20:01 +0000 admin http://www.softwaretools.in/digital-logic-simulation-with-the-intel-tbb-flow-graph-part-2-building-bigger-components A_port; broadcast_node < signal_t > B_port; broadcast_node < signal_t > CI_port; xor_gate < two_input > FirstXOR; xor_gate < two_input > SecondXOR; and_gate < two_input > FirstAND; and_gate < two_input > SecondAND; or_gate < two_input > FirstOR; graph& my_graph; void make_connections() { make_edge(A_port, FirstXOR.get_in(0)); make_edge(A_port, FirstAND.get_in(0)); make_edge(B_port, FirstXOR.get_in(1)); make_edge(B_port, FirstAND.get_in(1)); make_edge(CI_port, SecondXOR.get_in(1)); make_edge(CI_port, SecondAND.get_in(1)); make_edge(FirstXOR.get_out(), SecondXOR.get_in(0)); make_edge(FirstXOR.get_out(), SecondAND.get_in(0)); make_edge(SecondAND.get_out(), FirstOR.get_in(0)); make_edge(FirstAND.get_out(), FirstOR.get_in(1)); } public: one_bit_adder(graph& g) : my_graph(g), A_port(g), B_port(g), CI_port(g), FirstXOR(g), SecondXOR(g), FirstAND(g), SecondAND(g), FirstOR(g) { make_connections(); } one_bit_adder(const one_bit_adder& src) : my_graph(src.my_graph), A_port(src.my_graph), B_port(src.my_graph), CI_port(src.my_graph), FirstXOR(src.my_graph), SecondXOR(src.my_graph), FirstAND(src.my_graph), SecondAND(src.my_graph), FirstOR(src.my_graph) { make_connections(); } ~one_bit_adder() {} receiver < signal_t > & get_A() { return A_port; } receiver < signal_t > & get_B() { return B_port; } receiver < signal_t > & get_CI() { return CI_port; } sender < signal_t > & get_out() { return SecondXOR.get_out(); } sender < signal_t > & get_CO() { return FirstOR.get_out(); } }; This implementation is almost a straightforward translation of the gates and their connections into the flow graph format. The one complication is the addition of the broadcast_node s for each of the input ports. The reason for this is simply to enable connection to a single port from outside of the adder. Since each of the inputs is connected to two gates inside of the one_bit_adder object, there is no single port associated with them automatically. Adding the broadcast_node s enables us to provide the methods get_A , get_B and get_CI that each return a single port capable of receiving data. So, in looking at the diagram above, you can think of the three broadcast_node s as standing in for the black junction circles that the three inputs are connected to directly. To make the four_bit_adder class, simply chain together a set of four one_bit_adder s and connect the Carry-out port of each adder to the Carry-in port of the next adder, as shown in Figure 3 below: Figure 3 This time, the class is even more straightforward to implement, because no broadcast_node s are needed; every input already has exactly one internal connection. class four_bit_adder { graph& my_graph; std::vector < one_bit_adder > four_adders; void make_connections() { make_edge(four_adders[0].get_CO(), four_adders[1].get_CI()); make_edge(four_adders[1].get_CO(), four_adders[2].get_CI()); make_edge(four_adders[2].get_CO(), four_adders[3].get_CI()); } public: four_bit_adder(graph& g) : my_graph(g), four_adders(4, one_bit_adder(g)) { make_connections(); } four_bit_adder(const four_bit_adder& src) : my_graph(src.my_graph), four_adders(4, one_bit_adder(src.my_graph)) { make_connections(); } ~four_bit_adder() {} receiver < signal_t > & get_A(size_t bit) { return four_adders[bit].get_A(); } receiver < signal_t > & get_B(size_t bit) { return four_adders[bit].get_B(); } receiver < signal_t > & get_CI() { return four_adders[0].get_CI(); } sender < signal_t > & get_out(size_t bit) { return four_adders[bit].get_out(); } sender < signal_t > & get_CO() { return four_adders[3].get_CO(); } }; Here, the constructor makes a vector of exactly four adders, and connects the Carry-out ports to the Carry-in ports as appropriate. The multi-bit inputs and outputs have port access methods that take a bit as a parameter. So for example, to get the input port for bit 2 of input B, you would use get_B(2) . In Part 3 , I will present some interesting input and output devices to add to the logic simulation library, and with those, I’ll put together a small simulation that shows the four_bit_adder in action. ]]> http://www.softwaretools.in/digital-logic-simulation-with-the-intel-tbb-flow-graph-part-2-building-bigger-components/feed 0 http://www.softwaretools.in/intel-software-at-andevcon http://www.softwaretools.in/intel-software-at-andevcon#comments Mon, 14 May 2012 06:20:00 +0000 admin http://www.softwaretools.in/intel-software-at-andevcon http://www.softwaretools.in/intel-software-at-andevcon/feed 0 http://www.softwaretools.in/digital-logic-simulation-with-the-intel-tbb-flow-graph-part-3-putting-together-a-simulation http://www.softwaretools.in/digital-logic-simulation-with-the-intel-tbb-flow-graph-part-3-putting-together-a-simulation#comments Mon, 14 May 2012 06:19:59 +0000 admin http://www.softwaretools.in/digital-logic-simulation-with-the-intel-tbb-flow-graph-part-3-putting-together-a-simulation toggle_node; public: toggle(graph& g) : my_graph(g), state(undefined), toggle_node(g) {} toggle(const toggle& src) : my_graph(src.my_graph), state(undefined), toggle_node(src.my_graph) {} ~toggle() {} // Assignment ignored toggle& operator=(const toggle& src) { return *this; } sender < signal_t > & get_out() { return toggle_node; } void flip() { if (state==high) state = low; else state = high; toggle_node.try_put(state); } void activate() { state = low; toggle_node.try_put(state); } }; The toggle is represented internally by an overwrite_node , because it simply needs to keep track of one most-recent state. As an input device, it doesn’t receive output from any other items, so it has no explicit input ports, only actions (flip, activate) which can alter the output state. The output port can of course be acquired via get_out , so that the toggle can be used to send signals into a circuit. The pulse class is a little more interesting: class pulse { class clock_body { size_t& ms; int& reps; signal_t val; public: clock_body(size_t& _ms, int& _reps) : ms(_ms), reps(_reps), val(low) {} bool operator()(signal_t& out) { rt_sleep(ms); // our own portable sleep function if (reps> 0) --reps; if (val==low) val = high; else val = low; out = val; return reps> 0 || reps == -1; } }; graph& my_graph; size_t ms, init_ms; int reps, init_reps; source_node < signal_t > clock_node; public: pulse(graph& g, size_t _ms=1000, int _reps=-1) : my_graph(g), ms(_ms), init_ms(_ms), reps(_reps), init_reps(_reps), clock_node(g, clock_body(ms, reps), false) {} pulse(const pulse& src) : my_graph(src.my_graph), ms(src.init_ms), init_ms(src.init_ms), reps(src.init_reps), init_reps(src.init_reps), clock_node(src.my_graph, clock_body(ms, reps), false) {} ~pulse() {} pulse& operator=(const pulse& src) { ms = src.ms; init_ms = src.init_ms; reps = src.reps; init_reps = src.init_reps; return *this; } sender < signal_t > & get_out() { return clock_node; } void activate() { clock_node.activate(); } void reset() { reps = init_reps; } }; This class is based on the source_node . It generates a signal, alternating between low and high, every ms milliseconds. There is also an option to repeat the alternation a certain number of times and then stop, which is useful for designing simulations that use a clock but also terminate. The source_node body sleeps for a duration before flipping the signal and sending it. It doesn’t begin sending signals immediately, but requires activation. In the case of a non-infinite clock ( reps is set), once the pulse object has run for the given number of repetitions, it can be reset and reactivated to use it again. Next, we discuss two output devices, the LED and the digit . The LED is simply a tiny light that is on while the signal it is receiving is high, and off when the signal is low. For simple text display, the LED looks like this: (*) when it is on and ( ) when it is off. The digit device receives a four-bit input and displays a single hexadecimal digit. For simulations, both devices have the option of continuously displaying their state as it changes, or a silent mode, which displays only when a display method is called. class led { class led_body { signal_t &state; string &label; bool report_changes; bool touched; public: led_body(signal_t &s, string &l, bool r) : state(s), label(l), report_changes(r), touched(false) {} continue_msg operator()(signal_t b) { if (!touched || b!=state) { state = b; if (state != undefined && report_changes) { if (state) printf("%s: (*)n", label.c_str()); else printf("%s: ( )n", label.c_str()); } touched = false; } return continue_msg(); } }; graph& my_graph; string label; signal_t state; bool report_changes; function_node < signal_t, continue_msg > led_node; public: led(graph& g, string l, bool rc=false) : my_graph(g), label(l), state(undefined), report_changes(rc), led_node(g, 1, led_body(state, label, report_changes)) {} led(const led& src) : my_graph(src.my_graph), label(src.label), state(undefined), report_changes(src.report_changes), led_node(src.my_graph, 1, led_body(state, label, report_changes)) {} ~led() {} led& operator=(const led& src) { label = src.label; state = undefined; report_changes = src.report_changes; return *this; } receiver < signal_t > & get_in() { return led_node; } void display() { if (state == high) printf("%s: (*)n", label.c_str()); else if (state == low) printf("%s: ( )n", label.c_str()); else printf("%s: (u)n", label.c_str()); } }; The led class contains a simple function_node that has no meaningful output (we use a continue_msg to indicate this) and thus no successors. Another way to implement this would be with an overwrite_node , but we would lose the report_changes functionality. Similarly, the digit class also cannot have successors, but we reused the gate base class to implement it, since it has multiple bits of input and needs to update its state whenever one of the inputs changes. class digit : public gate < four_input > { using gate < four_input > ::my_graph; typedef gate < four_input > ::ports_type ports_type; typedef gate < four_input > ::input_port_t input_port_t; class digit_body { signal_t ports[4]; unsigned int &state; string &label; bool& report_changes; public: digit_body(unsigned int &s, string &l, bool& r) : state(s), label(l), report_changes(r) { for (int i=0; i < N; ++i) ports[i] = undefined; } void operator()(const input_port_t::output_type& v, ports_type& p) { unsigned int new_state = 0; if (v.indx == 0) ports[0] = std::get < 0 > (v.result); else if (v.indx == 1) ports[1] = std::get < 1 > (v.result); else if (v.indx == 2) ports[2] = std::get < 2 > (v.result); else if (v.indx == 3) ports[3] = std::get < 3 > (v.result); if (ports[0] == high) ++new_state; if (ports[1] == high) new_state += 2; if (ports[2] == high) new_state += 4; if (ports[3] == high) new_state += 8; if (state != new_state) { state = new_state; if (report_changes) { printf("%s: %xn", label.c_str(), state); } } } }; string label; unsigned int state; bool report_changes; public: digit(graph& g, string l, bool rc=false) : gate < four_input > (g, digit_body(state, label, report_changes)), label(l), state(0), report_changes(rc) {} digit(const digit& src) : gate < four_input > (src.my_graph, digit_body(state, label, report_changes)), label(src.label), state(0), report_changes(src.report_changes) {} ~digit() {} digit& operator=(const digit& src) { label = src.label; state = 0; report_changes = src.report_changes; return *this; } void display() { printf("%s: %xn", label.c_str(), state); } }; Because digit inherits from gate , it reuses gate ’s get_in methods to connect to the ports of a digit object. Here’s an example code to test out the four-bit adder. First, create a graph: graph g; Then, create the four-bit adder, some toggles with which to set the inputs to the adder, and a digit and an LED to display the output: four_bit_adder four_adder(g); std::vector < toggle > A(4, toggle(g)); std::vector < toggle > B(4, toggle(g)); toggle CarryIN(g); digit Sum(g, "SUM"); led CarryOUT(g, "CarryOUT"); Next, connect our toggles to the input ports of the adder, and connect the adder’s output ports to the display devices: for (int i=0; i g.wait_for_all(); Now display the results: Sum.display(); CarryOUT.display(); And here they are: SUM: d CarryOUT: ( ) And with that, I’ll wrap up this blog by saying that the logic simulation example code is available as an example in Intel® TBB 4.0 Update 4, and that it has several other interesting features, like push button and constant signal input devices, NAND and NOR gates, and a D-latch circuit example. Please let us know of other interesting use cases for the or_node and any other feedback you’d be willing to give. ]]> http://www.softwaretools.in/digital-logic-simulation-with-the-intel-tbb-flow-graph-part-3-putting-together-a-simulation/feed 0 http://www.softwaretools.in/preparing-for-augmented-reality-event-2012 http://www.softwaretools.in/preparing-for-augmented-reality-event-2012#comments Mon, 14 May 2012 06:19:58 +0000 admin http://www.softwaretools.in/preparing-for-augmented-reality-event-2012 http://www.softwaretools.in/preparing-for-augmented-reality-event-2012/feed 0 http://www.softwaretools.in/show-23-appup-show-at-sxsw-part-3-featuring-intel-lanfest-gaming-for-a-cause http://www.softwaretools.in/show-23-appup-show-at-sxsw-part-3-featuring-intel-lanfest-gaming-for-a-cause#comments Mon, 14 May 2012 06:19:57 +0000 admin http://www.softwaretools.in/show-23-appup-show-at-sxsw-part-3-featuring-intel-lanfest-gaming-for-a-cause http://www.softwaretools.in/show-23-appup-show-at-sxsw-part-3-featuring-intel-lanfest-gaming-for-a-cause/feed 0 http://www.softwaretools.in/meetup-html5-css3-pizzas-le-16-mai http://www.softwaretools.in/meetup-html5-css3-pizzas-le-16-mai#comments Mon, 14 May 2012 06:19:55 +0000 admin http://www.softwaretools.in/meetup-html5-css3-pizzas-le-16-mai http://www.softwaretools.in/meetup-html5-css3-pizzas-le-16-mai/feed 0 http://www.softwaretools.in/meshcentral-com-high-dpi-support http://www.softwaretools.in/meshcentral-com-high-dpi-support#comments Mon, 14 May 2012 06:19:54 +0000 admin http://www.softwaretools.in/meshcentral-com-high-dpi-support http://www.softwaretools.in/meshcentral-com-high-dpi-support/feed 0 http://www.softwaretools.in/seo-fundamentals-where-to-begin-when-optimizing-for-search-engines http://www.softwaretools.in/seo-fundamentals-where-to-begin-when-optimizing-for-search-engines#comments Mon, 14 May 2012 06:19:52 +0000 admin http://www.softwaretools.in/seo-fundamentals-where-to-begin-when-optimizing-for-search-engines http://www.softwaretools.in/seo-fundamentals-where-to-begin-when-optimizing-for-search-engines/feed 0 http://www.softwaretools.in/deterministic-reduction-a-new-community-preview-feature-in-intel-threading-building-blocks http://www.softwaretools.in/deterministic-reduction-a-new-community-preview-feature-in-intel-threading-building-blocks#comments Mon, 14 May 2012 06:19:51 +0000 admin http://www.softwaretools.in/deterministic-reduction-a-new-community-preview-feature-in-intel-threading-building-blocks http://www.softwaretools.in/deterministic-reduction-a-new-community-preview-feature-in-intel-threading-building-blocks/feed 0 http://www.softwaretools.in/is-pinterest-useful-to-software-businesses http://www.softwaretools.in/is-pinterest-useful-to-software-businesses#comments Mon, 14 May 2012 06:19:50 +0000 admin http://www.softwaretools.in/is-pinterest-useful-to-software-businesses http://www.softwaretools.in/is-pinterest-useful-to-software-businesses/feed 0